Installation endet mit einem Timeout

1st Official Post
    Affected App
    WoltLab Suite Forum

    Nabend,

    ich habe soeben versucht, dass WBB 4 zu installieren, allerdings geht's bei 58% nicht weiter. Ich habe das ganze bereits mehrmals probiert. Ich habe dabei das Verhalten der Prozesse beobachtet.

    Nachdem ich die Datenbankinformationen eingegeben habe und "Weiter" gedrückt habe, schießen 2 CPU Kerne kurz auf 100%, direkt danach kommt ein Datenbank Prozess, der für ca. eine Sekunde auf 100% geht, danach auf 0-1% und vor sich hin "ruht". Kurze Zeit später kommt ein nginx timeout. Am Server dürfte das nicht liegen, das ist ein sehr "entspannter" EX4 von Hetzner. Eine Installation vom WBB 3.1 hat problemlos geklappt.

    PHP Version: 5.3.3-7
    Server version: Apache/2.2.16 (Debian)
    MySQL: 5.1.66-0+squeeze1
    nginx: nginx version: nginx/1.0.4

    Liebe Grüße
    Keevin :)

    total 60K
    drwxr-xr-x 6 vu2003 vu2003 4.0K May 29 20:04 acp
    drwxr-xr-x 2 vu2003 vu2003 4.0K May 29 20:04 attachments
    drwxr-xr-x 2 vu2003 vu2003 4.0K May 29 20:04 cache
    -rw-r--r-- 1 vu2003 vu2003 217 May 29 20:04 config.inc.php
    drwxr-xr-x 2 vu2003 vu2003 4.0K May 29 20:04 font
    -rwxr-xr-x 1 vu2003 vu2003 394 May 29 17:29 global.php
    drwxr-xr-x 3 vu2003 vu2003 4.0K May 29 20:04 icon
    drwxr-xr-x 4 vu2003 vu2003 4.0K May 29 20:04 images
    drwxr-xr-x 3 vu2003 vu2003 4.0K May 29 20:04 js
    drwxr-xr-x 2 vu2003 vu2003 4.0K May 29 20:04 language
    drwxr-xr-x 9 vu2003 vu2003 4.0K May 29 20:04 lib
    drwxr-xr-x 2 vu2003 vu2003 4.0K May 29 20:04 log
    -rwxr-xr-x 1 vu2003 vu2003 915 May 29 17:29 options.inc.php
    drwxr-xr-x 3 vu2003 vu2003 4.0K May 29 20:04 style
    drwxr-xr-x 3 vu2003 vu2003 4.0K May 29 20:04 templates

    Irgendwie nicht. o:

    Ich habe das gleiche Problem.
    Danach habe ich versucht die DB-Tabellen zu löschen um die Installation zu wiederholen.
    Es bleiben immer einige Tabellen übrig die sich nicht ohne Weiteres löschen lassen wollen.
    Fehlermeldung:
    #1217 - Cannot delete or update a parent row: a foreign key constraint fails

    Um die Tabellen löschen zu können muss ich vor der Zeile Drop Table:
    SET FOREIGN_KEY_CHECKS=0;
    einfügen und danach:
    SET FOREIGN_KEY_CHECKS=1;

    Dann werden die Tabellen gelöscht.

    Sowohl in Firefox und Chrome trat der gleiche Fehler auf.
    Auf dem gleichen DB-Server laufen auch mehrere 3.1.7er problemlos.

    P.S.: Systemanforderungen sind einwandfrei.

    EDIT//
    Ich habe das nochmal wiederholt und die Webconsole mitlaufen lassen.
    Weiß ja nicht ob es hilft:
    [22:12:50.602] POST http://beta4.foren-verbund.org/install.php?step=createDB [HTTP/1.0 504 Gateway Time-out 60114ms]
    [22:13:51.267] Die Zeichenkodierung des HTML-Dokuments wurde nicht deklariert. Das Dokument wird in manchen Browser-Konfigurationen mit verstümmeltem Text dargestellt, wenn das Dokument Zeichen außerhalb des US-ASCII-Bereichs enthält. Die Zeichenkodierung der Seite muss im Dokument oder Transferprotokoll deklariert werden. @ http://beta4.foren-verbund.org/install.php?step=createDB

    Edited once, last by Schnoedewind (May 29, 2013 at 10:17 PM).

    Moin,

    ich hatte exakt das selbe Problem. Zufällig war es auch ein EX4 von Hetzner (wobei dieser nur der Wirt der virtuellen Maschine ist) .

    Bei 58% lächelte mich nach 120 Sekunden die Meldung "An internal server error occurred. Please try again later." an. Im error_log des Apachen stand auch nichts. Hat dann etwas gedauert bis mir eingefallen ist, dass ich Pound "vor" dem Apachen laufen habe und eben dieser ein Timeout bei 120 hatte. Nachdem ich den Timeout hochgesetzt habe, lief die Installation durch.

    Jetzt will ich nur noch rausfinden, warum dieser Schritt meinem Server überhaupt so lange beschäftigt. Er scheint recht viel Zeit bei der Ausführung der MySQL-Queries zu benötigen (dank Master/Slave-Replikation gleich zwei mal...).

    Ihr beide habt nicht zufällig ein ähnliches Setup auf euren Maschinen, so dass euch mein Hinweis hier hilft? :D

    Edited once, last by Heiko Bornholdt (May 30, 2013 at 11:33 AM).

    schaut mal pool konfiguration des php-fcgi nach, heisst glaub www.conf

    da müsste der eintrag
    request_terminate_timeout
    drinstehen.

    ist der Wert zu niedrig kommt es zum Timeout.
    Standardmäßig ist der auf 0, also off.

    Gruß

    Das Problem bleibt für mich auch in der Beta2 bestehen.
    Zugansdaten zur DB eingegeben ....

    dann loaded es sich zu Tode ....

    256 MB Memory-Limit und 200 Sek. Ausführungszeit.
    Wenn das nicht reicht ....

    Ein Lösungsvorschlag wäre FastCGI und "allow_url_fopen = on" zu nutzen.
    Desweiteren ist es hilfreich, die Konfiguration des Webservers zu ändern, in der fcgid.conf ( /etc/httpd/conf.d/fcgid.conf - oder auf Ubuntu Systemen = /etc/apache2/mods-available/fcgid.conf - falls nicht dort zu finden, nutzt die Funktion "locate fcgid.conf" über die Konsole, um die Datei auf dem Webserver zu finden ) :

    Code
    FcgidIdleTimeout 60
FcgidProcessLifeTime 90
FcgidIOTimeout 180


    ...danach Restart des Webservers.

    Wer keinen Zugriff auf diese Konfigurations - Dateien hat, kann seinen Webhoster bitten, diese Optionen einzustellen, wobei ich jedoch denke, dass die meisten Webhoster "allow_url_fopen = on" verbieten werden.

    Quote from Marcel Werk

    Bitte Zugangsdaten (FTP+MySQL) per E-Mail oder PN zur Verfügung stellen.

    Mache ich gleich fertig.

    Ich habe vom Support noch Details zur Konfiguration des DB-Servers gemacht.
    Antwort:

    wait_timeout = 12000
    interactive_timeout = 50
    connect_timeout = 10

    Vielleicht hilft das ja noch ...

    Mail mit Zugangsdaten ist raus ...

    Edited once, last by Schnoedewind (June 1, 2013 at 1:09 AM).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login