Aber ich habe - zugegebener Masse zu kurz darauf Eingegangen - von einer IPC-Verbindung gesprochen (Inter-Process-Communication). Damit meine ich die Kommunikation zwischen mod_fcgid und fcgid selbst.
IPC ist im weiteren Sinne alles, was die Kommunikation zwischen Prozessen erlaubt. Im engeren Sinne wird IPC oft für die System V IPC-Mechanismen (Shared Memory, Semaphores & Co) als Synonym verwendet. Bei FastCGI kommen üblicherweise Sockets (AF_UNIX, AF_INET, AF_INET6) zum Einsatz.
Sie wird nur i.d.R. über einen Unix-Socket aufgebaut. Theoretisch gibt es noch andere Möglichkeiten der IPC wie z.B. TCP-Socket, Named-Pipes oder Mutexs .
Ein Mutex hat mit IPC nicht direkt zu tun, sondern ist ein Mechanismus zum Schutz einer Ressource vor konkurrierenden Zugriffen; doch das nur am Rande. Völlig egal, ob Du einen Socket (welchen Typs auch immer), eine Pipe oder eine named Pipe verwendest - es handelt sich dabei immer um Dateideskriptoren, und in jedem Fall ist es einem Client-Prozess möglich, sich selbst zu beenden (oder beendet zu werden), ohne dabei den Server zu schießen.
Man muss sich bei FastCGI nur klar machen, dass der FastCGI-Prozess den Server spielt, und der Webserver den Client. Wird der FastCGI-Prozess unabhängig vom Webserver erzeugt (z. B. mit spawn-fcgi), ist selbiger völlig unbeeindruckt davon, wenn der Webserver-Prozess gekillt wird. Nur die besondere Konstellation, dass ein Webserver einen FastCGI-Prozess als Kindprozess selbst erzeugt, bringt eine etwas verzwickte Logik mit sich, da der FastCGI-Prozess die Dateideskriptoren von seinem Elternprozess, dem Webserver, erbt.
Außerdem sehen unixoide Systeme vor, dass ein Kindprozess beim beenden seinen Elternprozess darüber informiert, dass er sich beendet (und ggf. mit welchem Status). Gibt es keinen Elternprozess mehr, oder nimmt der Elternprozess keine Status-Information vom Kindprozess entgegen, entsteht aus dem Kindprozess ein Zombie - ein bereits abgearbeiteter Prozess, der sich nicht ganz beenden kann, weil er seinen Rückgabestatus nicht loswird.
Das nur zur Veranschaulichung, warum die Konstellation "Webserver erzeugt FastCGI-Prozess" so komplex ist. Das FastCGI-Modul muss sicherstellen, dass
- die Dateideskriptoren, die zur IPC benutzt werden, von beiden Prozessen sauber geschlossen werden (sonst bleiben sie in der Kernel-Tabelle als offene Deskriptoren drin und belasten das System)
- ein erzeugter FastCGI-Prozess sauber terminieren kann, d. h. sein Elternprozess noch aktiv ist und auch den Rückgabestatus entgegennimmt - ansonsten entstehen Zombies und müllen die Prozesstabelle voll.
Apache-Clients werden vom Parent-Prozess lediglich über ein TERM-Signal (also ein "Bitte beende Dich bei Zeiten") aufgefordert sich zu beenden.
Welches der Child aber nicht tut, weil er sich sagt: "Momentchen, ich habe da noch einen offenen IPC."
Dafür hat der Child einen Signal Handler, der
- ein Flag setzt, dass dafür sorgt, dass dieser Childprozess keine neuen Requests mehr zur Bearbeitung aus der Queue holt
- dafür sorgt, dass auf die noch in Abarbeitung befindlichen Requests (bei Worker = Threads) gewartet wird
- am Ende sicherstellt, dass alle offenen Dateideskriptoren geschlossen werden und einen Rückgabestatus setzt
Das bedeutet natürlich, dass der Child-Prozess noch eine Weile aktiv ist, nachdem er das TERM-Signal gefangen hat.
Es wäre in den meisten Installationen sinnvoll, wenn mod_fcgid das TERM per IPC auch an den fcgid durch reichen würde. Auf der anderen Seite macht es auch Sinn dies nicht zu tun, da fcgid theoretisch ein eigener Server ist und nicht nur von einem Apache-Child abhängig sein muss.
FastCGI-Prozesse werden nicht von den Child-Prozessen erzeugt, sondern von einem gesonderten Management-Prozess. Das FastCGI-Modul sollte dabei selbst erzeugten FastCGI-Prozessen ein TERM-Signal schicken, muss damit aber so lange warten, bis alle Apache-Children beendet wurden - die arbeiten bei einem TERM den aktiven Request ja noch zu Ende ab und müssen dabei ggf. von einem Socket lesen, der sie mit dem FastCGI-Prozess verbindet. Die o. g. Punkte müssen dabei natürlich beachtet werden.
