Philipp Hasenfratz: fork, reaper, Zombie-Prozesse und setsid

Beitrag lesen

Halihallo Martin

ich glaube wir sprechen ein wenig aneinander vorbei (was aber nicht tragisch ist).

Ja, was mein Fehler ist. Mit setsid bin ich über das eigentliche Thema geschossen ;)

Ich dachte, Du sagtest: wenn der Apache das Script killt, sobald kein STDOUT mehr existiert (was man tatsächlich auch abstellen kann - nur mein Provider scheinbar nicht), dann laß doch ein Sohn (der ein Dämon, weil autark vom Vater, ist) die Meldung machen (er terminiert sich ja eh selbst) (geht aber nicht, weil der Dämon-Sohn nicht an den Browser des Client kommt). Ich könnte auch den Vater die Meldung an den Browser ausgeben lassen, einen Dämon-Sohn zeugen lassen (klingt schon ordinär...), der den REst abarbeitet und der Vater läßt sich durch den Apachen killen (weil er STDOUT zumacht), nachdem er die Statusmeldung abgegeben hat.

Stimmt. Eine Weiterleitung der Daten des frühreren Childs wäre nur über IPC
(Inter Process Communication) möglich; nämlich dann, wenn der Parent die Daten wieder
an STDOUT sendet und das gilt es ja zu verhindern...

Geht aber auch nicht, weil der Dämon-Sohn trotzdem Ergebnisse an den Browser abgeben muß, und dort nicht hinkommt). Der Vater kann diese Meldungen aber via Pipe auch nicht mehr annehmen (wäre die einzige Verbindungsmöglichkeit), weil er nicht mehr exisiert.

Genau.

Wenn der Dämon-Sohn sich jetzt irgendwie festfrißt kann es sein, daß er sich selbst nicht mehr killen kann, und eine übergeordenete Instanz gibt es auch nicht mehr (Vater ist ja schon weg), außer den Administrator meines Providers. Er wäre ein Zombie. Also kann es kein Dämon sein.

Nicht ganz, ein Zombie ist ein bereits toter Prozess, deiner würde ja noch laufen, wenn
er sich selber nicht schliessen kann, aber naja, die Analogie stimmt schon :-)

Bleibt nur ein normaler Parallelprozess bei dem der VAter als Kontrollinstanz vom Sohn bestehen bleibt und informiert wird, wenn der Sohn terminiert (also kein Dämon), der sohn wird aber ebenfalls gekillt, wenn der VAter vom Apachen umgelegt wird (wenn er

"wenn der Vater vom Apachen umgelegt wird", you made my day! - Halleluja, mein Sohn ward
vom Apachen umgenietet, diese höllischen Flugmaschinen a.k.a Hellikopter... Ürgs! ;-)

Mein Problem ist, daß der Provider die Server-Pufferung nicht abschaltet (kann oder will). Hier liegt scheinbar die Lösungsmöglichkeit (weil eine ungepufferte Ausgabe, wie ich sie will, bei anderen Providern lauft). Im Moment verfolge ich deshalb zwei Möglichkeiten: einen eigenen kleinen http-server zu schreiben (der die Ausgabe ungepuffert über einen eigenen Port leitet), oder die Übertragunsgpakete mit unnützen Daten zu füllen (damit der Puffer geleert werden muß).

Naja, sind leider beides nur Workarounds, aber mir fällt leider auch nix gescheiteres
ein (was heisst hier eigentlich leider, es ist nunmal wirklich nicht Sinn des HTTP) :-(

Viele Grüsse

Philipp

--
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.