Was zu beachten ist
Sorgfältig arbeiten
Programme, die das CGI des Webservers nutzen, werden oft etwas schlampig erstellt, da solche Anwendungen nur für eine kurze Laufzeit geplant werden. Man sieht häufig, dass Speicherbereiche nicht freigegeben werden, oder Datenbankverbindungen nicht terminiert werden.
Dies sollte man sich auf gar keinen Fall bei Anwendungen erlauben, die das FastCGI nutzen. Der Speicherverbrauch des webservers würde linear ansteigen, oder im Falle der Datenbankverbindungen wären irgendwann keine neuen Verbindungen mehr möglich.
Bufferoverflows werden schnell zu einem massiven Problem. Es ist also empfehlenswert die Anwendungen genauestens zu debuggen und in einer Testumgebung unter Last zu setzen, bevor sie auf einem Produktiv-System eingesetzt werden.
Signale
SIGUSR1 an die Anwendung wird unter Umständen den Prozessmenager dazu veranlassen ein SIGTERM an alle laufenden FastCGI-Anwendungen zu senden. Der korrekte Weg eine Anwendung zu beenden ist SIGTERM. Das Signal-Handling von FastCGI-Anwendungen ist ein wenig knifflig, weshalb Sie unbedingt die Dokumentation lesen sollten, bevor Sie Signale nutzen.
Änderungen am Programm
Es ist nicht ausreichend ein Programm neu zu übersetzen. Die Änderungen werden erst wirksam, wenn das FastCGI neu gestartet wurde. Sie können hierzu die autoupdate Funktion in der httpd.conf nutzen, den Apache neu starten, oder über Pipes, Sockets, Signale, etc das Programm dazu veranlassen sich zu beenden. Wenn das FastCGI-Programm nicht läuft, weil es beendet wurde, wird das Modul die Anwendung beim nächsten Request starten.
Ein anderer Weg wäre das Programm selbst periodisch nach Änderungen schauen zu lassen und im Falle einer Änderung zu terminieren.