Error 500 bei simplexml_load_file

[Gerd H.]

Hallo Forengemeinde,

ich bin mit meiner Webseite auf einen neuen Server umgezogen. Seitdem bekomme ich bei einem Script ständig einen 500-Fehler. In den Log-Dateien finde ich nichts auffälliges.

Das Script:

• Liest große XML-Datei (bis zu 5 MB) ein
• Speichert diese in einer MySQL-DB

Beim alten Server lief das Script ohne Probleme.

Settings in der PHP.ini habe ich angepasst/erhöht:

max_execution_time = 6000
max_input_time = 120
memory_limit = 512M
post_max_size = 132M

Kann mir jemand helfen?

Danke und Gruß
Gerd H.

[Sven Rautenberg]

Moin!

ich bin mit meiner Webseite auf einen neuen Server umgezogen. Seitdem bekomme ich bei einem Script ständig einen 500-Fehler. In den Log-Dateien finde ich nichts auffälliges.

Wenn der Server selbst Status 500 zurückliefert, dann wird irgendein scriptinterner Fehler aufgetreten sein. Den findet man aber nur, wenn man die Fehlermeldung kennt. Und diese Fehlermeldung steht in irgendeinem Error-Logfile.

Settings in der PHP.ini habe ich angepasst/erhöht:

Wenn du das kannst, dann kannst du auch die Logfiles definieren und checken. Steht da was drin? Welche Dateien hast du überhaupt geprüft?

- Sven Rautenberg

[Gerd H.]

Scriptfehler kann ich eigentlich ausschließen, da erstens das Script auf dem anderen Server einwandfrei lief und zweitens das Script bei kleineren XML-Dateien funktioniert.

Wenn du das kannst, dann kannst du auch die Logfiles definieren und checken. Steht da was drin? Welche Dateien hast du überhaupt geprüft?

Ich habe die syslog und die error.log von Apache kontrolliert. Da ist eindeutig nichts auffälliges drin.

[Sven Rautenberg]

Moin!

Ich habe die syslog und die error.log von Apache kontrolliert. Da ist eindeutig nichts auffälliges drin.

Wo schreibt PHP eventuelle Fehler hin?

- Sven Rautenberg

[Gerd H.]

Wo schreibt PHP eventuelle Fehler hin?

Die Fehler werden in die /var/log/apache2/error_log geschrieben oder irre ich mich da?

[Sven Rautenberg]

Moin!

»» Wo schreibt PHP eventuelle Fehler hin?

Die Fehler werden in die /var/log/apache2/error_log geschrieben oder irre ich mich da?

Die Fehler werden dahin geschrieben, wo die Konfiguration in der php.ini es anzeigt. Das kann auch "nirgendwo" sein, und wenn parallel die Generierung von Fehlermeldungen in den Browser auch deaktiviert ist, dann gehen die Meldungen eben spurlos verloren.

Ist halt die Frage, was bei dir konfiguriert ist.

- Sven Rautenberg

[Gerd H.]

Danke Sven,

habe nun FastCGI deaktiviert und das Script wird wieder gewöhnlich ausgeführt.

Mir ist auch bewusst, dass es sehr rechenintensiv ist. Mit dem Script selbst werde ich mich später beschäftigen. bin erstmal froh, dass die XML-Datei in der Datenbank landet und die Webseite wieder normal läuft.

Da das Script auch nachts aufgerufen wird, bekommen nur wenige User dies wirklich mit(wenn überhaupt).

[Gerd H.]

So danke Sven bin ich dem Fehler nun langsam näher gekommen. In der PHP-Logdatei habe ich folgende 2 Einträge gefunden, die direkt nach AUsführung des Script hineingeschrieben werden:

mod_fcgid: read data timeout in 40 seconds  
Premature end of script headers: ins_xml.php

Über eine Suchmaschine habe ich herausgefunden, dass man den folgenden Eintrag in der /etc/apache2/mods-enabled/fcgid.conf anpassen muss, was auch logisch erscheint:

IPCConnectTimeout 40

Diesen hatte ich nun erhöht, Script aufgeführt und ich erhalte trotzdem den Fehler "mod_fcgid: read data timeout in 40 seconds".

Scheinbar wird trotz Apache-Neustart die neue Konfiguration nicht übernommen...

[Sven Rautenberg]

Moin!

mod_fcgid: read data timeout in 40 seconds

Premature end of script headers: ins_xml.php

>   
> Über eine Suchmaschine habe ich herausgefunden, dass man den folgenden Eintrag in der /etc/apache2/mods-enabled/fcgid.conf anpassen muss, was auch logisch erscheint:  
>   
> `IPCConnectTimeout 40`{:.language-php}  
>   
> Diesen hatte ich nun erhöht, Script aufgeführt und ich erhalte trotzdem den Fehler "mod\_fcgid: read data timeout in 40 seconds".  
>   
> Scheinbar wird trotz Apache-Neustart die neue Konfiguration nicht übernommen...  
  
Gibts Gründe, dass du das PHP-Skript mit fast-cgi ausführen lässt? Die übliche Konstellation, wenn man einen eigenen Server nutzt, wäre doch als Apache-Modul.  
  
Ansonsten wäre als Grund für die Nichtreaktion auch einfach möglich, dass du die falsche Datei geändert hast.  
  
Und so vom Gefühl her klingt das auch alles noch nicht wirklich so, als ob du an den richtigen Stellschrauben drehst. Ich vermute einfach, dass dein PHP-Skript durch irgendeinen Seiteneffekt, der auf dem alten Server nicht aufgetreten ist, zuviel Speicher braucht oder sonst irgendeinen Grund für ein unerwartetes Ende hat. Vielleicht auch, weil die zu erledigende Aufgabe einfach zuviel Zeit benötigt und deshalb von der Laufzeitbegrenzung abgebrochen wird.  
  
Mir fehlen Erfahrungswerte mit fast-cgi, aber ich könnte mir vorstellen, dass das Ausbleiben von regelmäßigen Ausgaben während der Ausführung dann den IPC-Timeout triggert - oder grundsätzlich das Skript keine Ausgaben (und auch keine Fehlermeldung) liefert und unbemerkt schon tot ist, während fast-cgi noch auf Ausgaben wartet, bis der Timeout zuschlägt.  
  
Du kannst dem Skript ja mal Log-Ausgaben mittels error\_log() hinzufügen, um zu prüfen, wie weit es tatsächlich abgearbeitet wird. Diese Log-Ausgaben landen dort, wo PHP auch seine Fehlermeldungen hinschreibt. Dran denken, dass es mehrere php.ini gibt, für jede SAPI eine eigene. Welche dein Skript nutzt, und auch welche Log-Konfiguration aktiv ist, sagt dir phpinfo().  
  
 - Sven Rautenberg