PHP5-FPM stirbt sporadisch

MadMakz

MadMakz

Active Member
OS: Debian Wheezy
Panel: ispConfig3
HTTP: Apache 2.2.22 (Stock)
PHP: 5.4.36 FPM (DotDeb)
Fehler:
Seit ewigkeiten plagt mich das Problem das anscheinend das FPM-Socket eines Bestimmten vHost ,scheinbar ohne Grund und sehr sporadisch, stirbt.

Auf dem vHost läuft eine WordPress-Multisite Instanz mit PHP-APC.

PHP Log schmeißt nichts vernünftiges heraus.
PHP-FPM Log
Code: 
...
[29-Dec-2014 11:54:55] WARNING: [pool web1] child 17847 exited on signal 11 (SIGSEGV) after 0.030370 seconds from start
[29-Dec-2014 11:54:55] NOTICE: [pool web1] child 17848 started
[29-Dec-2014 11:56:17] WARNING: [pool web1] child 18199 exited on signal 11 (SIGSEGV) after 0.038365 seconds from start
[29-Dec-2014 11:56:17] NOTICE: [pool web1] child 18200 started
[29-Dec-2014 11:56:19] WARNING: [pool web1] child 18200 exited on signal 11 (SIGSEGV) after 1.974629 seconds from start
...
Apache quittiert Anfragen mit einem 500 Server Error und folgnden Logeinträgen (pro Request)
Code: 
...(104)Connection reset by peer: FastCGI: comm with server "/var/www/clients/client1/web1/cgi-bin/php5-fcgi-*-80-example.com" aborted: read failed, referer: ...
Ser häufig scheint es Referrer-Spam (Track-/Pingback versuche) zu sein der den vHost lahm legt.

Warum FPM mit einem SIGSEGV abstürzt kann ich mir nicht erklären.

Nach einem
Code: 
service php5-fpm reload
läuft alles ganz normal weiter, bis zum nächsten sporadischen Ausfall.

Manchmal läuft es Tagelang ohne Probleme, manchmal passiert es zwei mal am Tag.

Alle anderen vHosts haben dieses Problem nicht Darunter auch eine Piwik Instanz die wesentlich mehr Anfragen abarbeiten muss.
 
Last edited by a moderator:
Mit was für einem MPM läuft Apache? Ich hatte vor ein ca. 1 Jahr ein ähnliches Problem (ebenfalls WP, und ebenfalls nicht nachvollziehbare SIGSEGVs und oft auch Processhänger).
Die Ursache konnte nie aufgeklärt werden aber das Phänomen trat nur mit ITK MPM auf...vor dem Wechsel von Worker MPM und auch nach dem Wechsel darauf zurück nicht bzw. nicht mehr.
 
Danke schon mal. MPM ist Worker.

Ich werde morgen mal die Einstellungen so weit abändern das ich vielleicht mal einen Coredump bekomme.
Hoffentlich bringt das etwas neues.
 
Klemm dich doch mal mit strace an die entsprechenden PHP-FPM-Worker. Ist nicht immer leicht zu analysieren, liefert aber wirklich oft Lösungsansätze wegen der vielen Details.

Ansonsten hat PHP-FPM einige "Emergency Restart"-Direktiven, die das Problem zwar zweifelsfrei nicht lösen, aber ein Umschiffen wird damit manchmal sehr leicht.
 
Stimmt, danke :)

Ich habe zwischenzeitlich auf gut Glück einfach mal die pm.max_children höher geschraubt.
Läuft derzeit seit 8 Tagen ohne Probleme.

Ob ich damit das Problem gelöst oder nur einen größeren Puffer gebaut habe weiß ich nicht.
Falls das die Lösung war dan mal wieder Hut ab an PHP für die Kryptischen Fehlermeldungen.
 
Ist etwas komisch. Wie schafft man es mit zu wenig Workern eine Schutzverletzung zu generieren? Wenn du jetzt nicht geschrieben hättest, dass der Mist jetzt seit 8 Tagen ohne Probleme läuft, wäre ich eher von einem Fehler im PHP-Script ausgegangen, welches den Interpreter irgendwie zum Absturz bringt.
 
DeaD_EyE said:
...Wenn du jetzt nicht geschrieben hättest, dass der Mist jetzt seit 8 Tagen ohne Probleme läuft, wäre ich eher von einem Fehler im PHP-Script ausgegangen, welches den Interpreter irgendwie zum Absturz bringt.
Click to expand...
Dito. Und ich habe "no friggin' idea".
Ich werde kommendes Wochenende nochmal damit Spielen und schauen ob ich es irgendwie erzwingen kann.
Nach der Logik sollte es mit max_children 1 ja schnell gehen :D
 
Ein coredump kommt irgendwie nicht zustande.

Hier mal ein kurzer auszug aus strace.
Code: 
[pid 19147] open("/var/www/clients/client1/web1/web/wp-includes/pluggable.php", O_RDONLY) = 5
[pid 19147] fstat(5, {st_mode=S_IFREG|0644, st_size=74753, ...}) = 0
[pid 19147] mmap(NULL, 74753, PROT_READ, MAP_SHARED, 5, 0) = 0x7f3448983000
[pid 19147] munmap(0x7f3448983000, 74753) = 0
[pid 19147] close(5)                    = 0
[pid 19147] brk(0x3015000)              = 0x3015000
[pid 19147] lstat("/var/www/clients/client1/web1/web/wp-includes/pluggable.php", {st_mode=S_IFREG|0644, st_size=74753, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1/web1/web/wp-includes", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1/web1/web", {st_mode=S_IFDIR|0711, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1/web1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1/web1/web/wp-includes/pluggable.php", {st_mode=S_IFREG|0644, st_size=74753, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1/web1/web/wp-includes", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1/web1/web", {st_mode=S_IFDIR|0711, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1/web1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1/web1/web", {st_mode=S_IFDIR|0711, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1/web1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients/client1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www/clients", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 19147] stat("/var/www/clients/client1/web1/web/wp-includes/pluggable.php", {st_mode=S_IFREG|0644, st_size=74753, ...}) = 0
[pid 19147] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 19147 detached
Vollständger strace: http://madmakz.com/get/dump/strace_web1.txt
:(
 
1) Schmiert er immer nach der /var/www/clients/client1/web1/web/wp-includes/pluggable.php ab oder ist das jeweils unterschiedlich?
2) Hast du mal einen memcheck laufen lassen auf dem Server? Segfaults können leider ohne Ende Ursachen haben...
 
PHP-Friends said:
1) Schmiert er immer nach der /var/www/clients/client1/web1/web/wp-includes/pluggable.php ab oder ist das jeweils unterschiedlich?
2) Hast du mal einen memcheck laufen lassen auf dem Server? Segfaults können leider ohne Ende Ursachen haben...
Click to expand...
Ja es ist immer die pluggable.php

Zur Sicherheit läuft gerade dennoch ein Memtest. Danach werde ich noch das Dateisystem prüfen.
 
Last edited by a moderator:
Was steht denn im Code der besagten Datei? Ich bin kein Programmierer, aber vielleicht kann ja jemand vom Fach was dazu sagen. :)

Ansonsten: Lässt sich das Skript fehlerfrei auf der Konsole ausführen?
 
Update:

HDD geprüft OK, RAM geprüft OK (8 Durchläufe mit memtest86)

Ich gehe mittlerweile davon aus das ein oder in kombination mehrerer WordPress Plugins das Problem ist vor allem da das Problem über mehrere WP-Versionen hinweg existiert (Daher kann es auch keine korrupte pluggable.php sein).

Weiß jemand zufällig ob ein Segfault in PHP auch durch zu viele Notice/Warning Nachrichten entstehen kann?

Den Bugtracker habe ich auch einmal angefangen zu durchforsten aber da gibt es eigentlich noch keine Hilfe.
https://bugs.php.net/bug.php?id=67954
https://bugs.php.net/bug.php?id=66554
https://bugs.php.net/bug.php?id=68781

Beim nächsten Crash werde ich APC abstellen und wenn das nicht hilft werde ich mal PHP 5.6 probieren, war sowieso für irgendwann dises Jahr geplant. Ich denke WordPress sollte damit zurrecht kommen, Pluginfehler könnte ich zur Not selbst beheben.

So langsam nervt mich das ich den Grund nicht finde und kein Coredump kommt. :(
 
Last edited by a moderator:
Update2: Bin gerade dabei einen neuen Server auf zu setzen und siehe da, wie der Zufall es will, ist es offensichtlich ein FPM "ondemand" Problem!

Man kann es ganz einfach reproduzieren:

Nginx 1.6.2
PHP 5.6.4 (pm = ondemand)

Script phpmyadmin 4.3.6,
nach Login (z.T. auch direkt) bekommt man im Browser einen 502 Gatewa Fehler und in der fpm.log bekommt man
Code: 
child 21668 exited on signal 11 (SIGSEGV) after 1.637180 seconds from start

php.ini ist bis auf cgi.fix_pathinfo=0 im standart.

Setzt man pm = static kommt es zu keinen fehlern.

Das ließ sich bei mir jetzt zu 100% Reproduzieren.

Zu einem Coredump kommt es nach wie vor nicht.
 
Last edited by a moderator:
Es gibt auch schöne Webapplikationen für Python. Mir ist mal aufgefallen, dass der Code viel strukturierter ist, als PHP jemals sein wird. Was mich wundert, dass trotzdessen PHP ganz weit vorne liegt, was Webapplikationen angeht. Wahrscheinlich ist es das Henne-Ei-Problem. Mir fällt jetzt kein Massenhoster mit Python-Support ein.

Gibt es nicht auch für PHP eine Art Debugserver? Wäre auf jeden Fall besser, als den Nginx oder Apache dazwischen zu haben, wenn man diese schon mal als Fehlerquellen ausschließen will.
 
Muss meine letzte Antwort ändern:
Mit 5.4.36 lässt es sich mit phpmyadmin nicht so einfach reproduzieren. Ich denke aber dennoch das dort irgenwo das Problem liegen wird wenn es in 5.6 schon so erheblich ist das die PHP Applikation quasi gar nicht erst startet.

Ich hab mich selber auch auf PHP eingeschossen muss ich ja gestehen :S

Lag wohl daran das es mehr fertige Sachen und auswahl bei PHP gab, z.B. die Masse an CMSystemen ist schon immens.
 
You must log in or register to reply here.
Back
Top