Rainer Duffner wrote:
> Nachdem ich gestern Mittag mal php-fpm reloaded habe, ist das gleiche
> wieder passiert.
> Es ist also (mit ziemlicher Sicherheit) das rc.d Script von php-fpm.
Oder php-fpm selbst.
> (bla <local>) 0 % php -v
> PHP 5.3.17 with Suhosin-Patch (cli) (built: Oct 15 2012 17:41:03)
> Copyright (c) 1997-2012 The PHP Group
> Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
>
> Oder wie muss ich das verstehen?
> Wie kann sowas eigentlich sein?
Als erstes würde ich mal nachsehen, ob die richtige PID in
/var/run/php-fpm.pid steht (d.h. mit der Ausgabe von ps
vergleichen).
Wenn das passt, würde ich als nächstes mal versuchen, den
php-fpm manuell zu restarten, also manuell mit kill (ohne
das rc.d-Skript). Das rc.d-Skript schickt ein SIGQUIT,
also würde ich das als erstes versuchen (kill -QUIT ...,
dann mit ps gucken, ob es wirklich beendet wurde, dann neu
starten). Die diversen Signale sind in der Manpage von
php-fpm dokumentiert.
Wenn es dann keinen Shutdown gibt, ist der Fehler im rc.d-
Skript. Dann müsste man sich das mal näher ansehen.
Gibt es aber wieder einen Shutdown, dann ist der Fehler in
php-fpm selbst. Ich verwende php-fpm nicht selbst, daher
kann ich dazu aus dem Stegreif reine Details sagen, aber
wenn es als root gestartet wird (was offenbar der Fall
ist), kann es prinzipiell auch ein Signal an init schicken
und somit einen Shutdown herbeiführen. Sicherlich nicht
absichtlich, aber als Folge eines Bugs (php-fpm ist ja auch
noch als "experimentell" gekennzeichnet).
Da php-fpm (bzw. der Hauptprozess) diverse Child-Prozesse
verwaltet und diese selbst stoppt und startet, muss es auch
mit diversen Signalen hantieren, und wenn dort nun irgend-
ein ganz blöder Bug enthalten ist, der dazu führt, dass
php-fpm glaubt, einer seiner Child-Prozesse habe die PID 1,
dann führt es genau zu dem beobachteten Verhalten.
Evtl. enthält php-fpm Debug-Optionen, die in dem Fall eine
weitere Untersuchung ermöglichen.
Es wurden ja hier schon mehrere Vorschläge gemacht, wie man
verhindern kann, dass an PID 1 ein Signal geschickt werden
kann (z.B. Einsperren in ein Jail). Das behebt aber nicht
den grundlegenden Bug, d.h. es würde dann möglicherweise
dazu führen, dass Child-Prozesse nicht ordentlich gekillt
werden und "ewig" herumhängen. Aber einen Versuch ist es
aber evtl. trotzdem wert, falls man auf anderem Weg nicht
weiterkommt.
Gruß
Olli
-- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code" (taken from comp.lang.awk FAQ) To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Fri 09 Nov 2012 - 11:57:31 CET