php-fpm nginx Konfiguration, exited on signal 6

stefkey

Member
Hallo,

ich versuche eine stabile php7-fpm+nginx configuration für mein Neos CMS zu konfigurieren. Es will nicht gelingen. Hat zufällig jemand Neos, Typo3 /Flow auf seinem Server mit nginx und php-fpm laufen und könntest du hier deine Konfiguration posten?

Im Log stehen bei Nutzung von Neos dauernd solche Meldungen
child 27440 exited on signal 6 (SIGABRT) after 16.954250 seconds from start

Oder wie kann ich einkreisen warum php aussteigt?

RAM hats genug auf der Maschine.

Wie kann ich den Fehler finden? Hat jemand einen Vorschlag für mich.
 
Nein, aber damals scheint es ein Bug gewesen zu sein auf Debian OS. Ich hatte auf Ubuntu gewechselt, dort gab es keine Probleme damit. Ob es heute mit Debian klappen würde weiß ich nicht. Nutzt du Neos auf einem Debian und hast das gleiche Problem aktuell?
 
Wie ein Bug kommt es mir auch vor – aber so ein Bug wäre ja sofort behoben...

Nutze TYPO3 7.6 auf jetzt frisch aktualisiert auf PHP 7.0.18. Ich bekomme sporadisch Fehler 500. Gleicher Aufruf funktioniert aber dann wieder – oder bringt eben den Fehler.

In der PHP FPM Log steht dazu dann eben der "Signal 6 (SIGABRT)" Fehler und danach erstellt er sofort ein neues Child.

Es ist zum Eierlegen – der Server hat genau eine Auslastung von 0 – ist nur für die Entwicklung bei mir im Büro und nur ich greife quasi auf den vHost zu. Nutze allerdings Apache – aber der Fehler kommt ja vom FPM Server, daher sollte das wohl wurscht sein.

Eine einfache test.php mit phpinfo(); kann ich aktualisieren wie ich möchte – da passiert das nicht. Bei meinem PHP 5 FPM Server läuft auch alles scheinbar sauber.
 
ganz genau, es war zum verzweifeln! Ich konnte es nicht lösen, bin allerdings nicht der Fachmann, aber habe mind. 20 Stunden gesucht und keine Lösung gefunden.

Mit Ubuntu gab es dann keine Probleme, ich wollte ungern wechseln, aber mir blieb nichts anderes übrig.
 
Kann sein, dass es Probleme mit System-Bibliotheken gibt.

Steht irgendwas im Kernel-/Syslog?

PS: Ein bisschen Mitarbeit schadet nicht. Es wäre schon nützlich, wenn ihr mal genauer angeben würdet welches OS und PHP ihr habt!
 
Last edited by a moderator:
Debian Jessie, aktuellste Version.
PHP 7.0.18. Apache 2.4.x.

Muss ich aber sonst noch mal nachschauen - gerade nicht verfügbar.

Kann ich nicht einfach das Ubuntu Paket installieren? Systeme sind doch quasi gleich, oder? Oder selbst kompilieren? Sollte das Problem ja lösen wenn es ein Paketproblem ist.

PS: Im syslog steht nichts wenn der Fehler auftritt.
 
Last edited by a moderator:
Kann ich nicht einfach das Ubuntu Paket installieren?
Systeme sind doch quasi gleich, oder?
Oder selbst kompilieren?
Sollte das Problem ja lösen wenn es ein Paketproblem ist.
Meine Antwort auf deine Fragen wie in deiner Reihenfolge:
Nein, kann funktionieren, muss nicht. Ubuntu ≠ Debian.
So eine Installation aus Ubuntuquellen traue ich mich gerade mal auf dem Desktop, da ist es wurscht wenn was hakt. Aber auf einem produktiven Server aus Fremdquellen!? :eek:

Nein.
Ubuntu ist mehr ein Rolling Release. Debian macht Fixes konservativer.

Wen du Erfahrung hast, ja.
Wenn du dich traust, dein System instabil zu machen und gut debuggen kannst. Mach nur, du kannst auch dein System wieder neu aufsetzen.

Vielleicht (siehe auch vorherige Antwort).
Ob es ein Paketproblem ist, weiß ich nicht, ich bin kein PHP-Maintainer.

Schaut doch einfach mal in den Bugtracker eures Server-OS rein, ob da was drin steht.
 
Danke für den Link. Teste ich in laufe des Tages. Aber klingt ja schon nach der Lösung - habe auch ewig gegoogelt - wieso ich das nicht gefunden habe ist mir ein Rätsel.

Frage mich allerdings auch warum das nicht in stable gefixt wird - so kann ja scheinbar niemals ein PHP 7 auf Debian Jessie mit FPM laufen. Zumindest bei bestimmten Systemen wie TYPO3.

Naja...

Danke dir vielmals!
 
Frage mich allerdings auch warum das nicht in stable gefixt wird
Weil es kein Security-Bug ist und Debian nur Security-Bugs, welche auch explizit als Solche im offiziellen Changelog markiert sind, fixed und keine normalen Bugs, denn das könnte ja die "Stabilität" des Systems gefährden.

Einer der Top-Punkte die gegen den Einsatz von Debian für produktive Systeme spricht...
 
Back
Top