Redio Blog

Seit einiger Zeit beobachte ich dieses Phänomen nun schon: Plötzlich — wie aus dem Nichts — werden von FastCGI/PHP keine Anfragen mehr bearbeitet. Es gibt nur noch einen Timeout und den damit verbundenen “Internen Serverfehler”. So auch heute wieder zwischen 12:20 und 13:00 Uhr.

Typische Log-Einträge sind dann:

[error] FastCGI: comm with (dynamic) server "/usr/local/fcgi-bin/fcgi-php-user" aborted: (first read) idle timeout (30 sec)
[error] FastCGI: incomplete headers (0 bytes) received from server "/usr/local/fcgi-bin/fcgi-php-user"

oder auch

[error] (4)Interrupted system call: FastCGI: comm with server "/usr/local/fcgi-bin/fcgi-php-user" aborted: select() failed
[error] FastCGI: incomplete headers (0 bytes) received from server "/usr/local/fcgi-bin/fcgi-php-user"

Letztere Meldung lässt sich angeblich durch ein Update von mod_fastcgi beheben. Das wird wohl auch für Redio mal fällig.

Update: Ich sehe gerade, dass die Apache Foundation die Rechte an mod_fcgid übernommen hat und das Modul aktiv weiterentwickelt. Das wäre sicherlich die bessere Alternative, als weiterhin auf mod_fastcgi zu setzen, das schon mehr als eine Jahr kein Update mehr erfahren hat.

Seit acht Tagen gibt es nun PHP 5.2.11, inklusive “Security Enhancements”. Installiert ist es aber noch nicht? — Doch, schon.

Es gibt nur ein Problem: Diese Version ist wesentlich instabiler als 5.2.10. Ein Vergleich: In den letzten 24 Stunden gab es mit 5.2.10 ganze Null(!) Segfaults (also Fehler beim Zugriff auf den Speicher, die zum Absturz des Programms führen). PHP 5.2.11 hingegen häuft (morgens) in drei Stunden 23 Stück davon an. Hochgerechnet auf einen Tag dürften es also 200 und mehr werden. Das heißt aber auch 200 Zugriffe, bei denen ein Benutzer nur einen “500er” Serverfehler zu sehen bekommt. Das hört sich, bei einigen hunderttausend Hits pro Tag, nicht viel an, aber es ist — im Vergleich zur vorherigen Version — zu viel und einfach nicht akzeptabel.