Sporadischer 500 - premature end of script bei fcgid/Apache2

Christopher

New Member
Hallo zusammen,

wir bekommen sporadisch die Apache 2 Fehlerseite "500 Internal Server Error" angezeigt und ich hab bisher noch auf keine Lösung gefunden. Hier mal die genaue Erklärung:

Setup:
  • Ubuntu 8.04 LTS
  • Apache2
  • MPM worker
  • mod fcgid
  • PHP 5.2.4-2ubuntu5.6 with Suhosin-Patch 0.9.6.2
  • APC Advanced PHP Accelerator
  • dickster Dual Quadcore Serverloft Server
  • dedicated root server (kein suExec oder so)

Fehlerbeschreibung:
Prinzipiell funktioniert die Seite gut, nur bekommen wir gelegentlich die oben genannte Apache2 500 Internal Server error Fehlerseite. Gelegentlich bedeutet hier: In den letzten 4 Tagen ca. 120 mal bei ~200.000 page impressions.

Der Fehler tritt jeweils sofort auf. Soll heißen, wenn es passiert, lädt die Seite nicht lange rum, sondern gibt den Fehler so schnell wie einen 404er.

Der zugehörige Apache2 Error log Eintrag lässt auf ein Problem mit fcgid schließen:
Code:
[Tue May 12 11:35:54 2009] [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error.
[Tue May 12 11:35:54 2009] [error] [client xxx.xxx.xxx.xxx] Premature end of script headers: index.php, referer: http://xxx/index.php
[Tue May 12 11:35:57 2009] [notice] mod_fcgid: process /var/www/current/index.php(10249) exit(communication error), terminated by calling exit(), return code: 0


Config Settings
fcgid:
Code:
<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi
  #IPCConnectTimeout 20

  # The connect timeout to a fastcgi application.
  IPCConnectTimeout 30

  # IPCCommTimeout n (20 seconds)
  # The communication timeout to a fastcgi application. Please increase this
  # value if your CGI have a slow initialization or slow respond.
  IPCCommTimeout 120
</IfModule>
(Siehe hier für eine Übersicht von fcgid Einstellungen.)

Sonstige Apache Config (Auszug):
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15

<IfModule mpm_worker_module>
StartServers 2
MaxClients 175
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>

<Directory /var/www/current/>
AddHandler fcgid-script .php
FCGIWrapper /usr/lib/cgi-bin/php5 .php
Options ExecCGI -Indexes FollowSymLinks
AllowOverride All
Order allow,deny
allow from all
</Directory>

Evtl. relevante PHP config:
Code:
extension = apc.so
apc.enabled = 1
apc.shm_size = 48
apc.include_once_override = 1
apc.mmap_file_mask = /tmp/apc.XXXXXX

max_execution_time = 30     ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
memory_limit = 128M      ; Maximum amount of memory a script may consume (16MB)



Fehleranalyse
Die meisten Fehlerbeschreibungen, die ich gefunden habe gehen auf diesen Fehler ein, wenn fcgid überhaupt nicht funktioniert. Wie gesagt tritt der Fehler bei uns nur sehr selten auf.
Diese Quelle beschreibt mögliche Probleme mit flaschen End-of-line Charactern in den auszuführenden Skripten bzw. mit falschen Dateiberechtigungen. Wie gesagt bei uns eher nicht der Fall, da es sonst ja immer auftreten würde. (Habs natürlich außerdem überprüft).

Diese Quelle wiederrum argumentiert mit falschen Timeouts, welche wir auch erhöht haben. Der Umstand, dass der Fehler, wenn er auftritt, ohne jegliche Wartezeit angezeigt wird lässt mich auch daran Zweifeln, ob es Timeouts sind, die hier das Problem machen.

Ich meine irgendwo gelesen zu haben, dass evtl. abweichende Memory Einstellungen für PHP und fcgid Probleme machen könnten. Ich find aber unter diesen Stichworten leider nichts mehr in die Richtung.

Hat jemand Ideen?

Gruß,
christopher
 
premature end of script bei fcgid/Apache2

Hallo Christopher!
Konntest du das Problem eigentlich lösen?
Bin gerade auf dein Posting gestoßen, da ich mit ähnlichen Problemen kämpfe.
Die ersten Abrüche nach 40 Sekunden konnte ich stoppen, nachdem ich im Vhost Container den IPCCommTimeout gesetzt und erhöht habe.
Jetzt brechen die Scripte aber nach ca., aber immer nur ca. 360 Sekunden mit
dem Error Eintrag Premature end of script headers... ab.
Ich finde, diese zeitliche Ungenauigkeit hört sich mehr nach deiner letzen Bemerkung zur evtl. abweichenden Memory Einstellung von PHP und fcgid an.

Gruß Felix
 
Hallo feliks,

wir konnten das Problem leider nicht lösen. Ein Paar Tage nachdem ich das hier geposted habe wurde es sogar noch schlimmer und unserer ganzer Apache ist abgeschmiert und lies sich nicht wieder neu starten. Wir hatten in dem Moment einiges an Load auf der Seite, da alle unsere User offenbar auf F5 rumgehämmert haben. Der Apache hat dann ununterbrochen diese Fehler geschmissen und war auch durch runterschrauben von erlaubten parallelen Verbindungen nicht dazu zu überreden, einen Zustand zu erreichen in dem er auch nur eine einzige Seite ausliefern konnte.

Ich hab wohl oder übel dann den MPM prefork wieder mit mod PHP installiert. Ich bin überrascht, dass der worker mit fcgid in anderen Installationen offenbar stabil läuft. Bei uns machte er den Eindruck einer total instabilen Alpha Version :(

Nichtsdestotrotz bin ich aber auch sehr daran interessiert zu hören, was für Erfahrungen andere Leute in die Richtung hier gesammelt haben... Da es bei anderen ja geht hab ich den Verdacht irgendein grundlegendes Konzept von dem Ding nicht verstanden zu haben und das ärgert mich natürlich ;)

Grüße,
christopher
 
Gibt es dazu Neues? Denn genau seit gestern tritt dieses Phänomen auch auf.

Auch Ubuntu mod fcgid.

Die anderen VHosts unter Plesk laufen prima (auch fast cgi)

Die Logs sind bei mir auch die gleichen. Es läuft eine joomla Installation darauf. Hat jemand einen Rat?
 
Hallo,

von unserer Seite aus gibt es da nichts neues. Wir fahren wieder den prefork mit mod_php und der läuft bei uns äußerst stabil. Nicht ein einziger Absturz in 6 Monaten.

Da geb ich lieber ein Paar Euro mehr für zusätzliche Hardware aus als mich mit dem instabilen Zeug weiter rumzuärgern nur weil es "einen kleineren footprint" hat...

Wenn Du was herausfindest aber bitte trotzdem schreiben.
 
Das Problem kenne ich. Die genaue Ursache dafür habe ich nie herausgefunden. Ich vermute einen Zusammenhang mit der Ressourcenauslastung des Servers sowie den benötigten Apache- und damit PHP-Prozessen. Zumindest war mein Gefühl, dass der Fehler häufiger auftrat, wenn etwas mehr auf dem Server los war - wobei man von "Auslastung" nicht wirklich reden konnte (was IMHO darauf hindeutet, dass evtl. nicht genug Prozesse/Threads für die Abarbeitung zur Verfügung stehen).

Seit langer Zeit tritt der Fehler bei uns nicht mehr auf (Debian Lenny). Allerdings verwenden wir nicht das mitgelieferte FCGI-Mod sondern fastCGI, welches wir mit apxs2 direkt als Modul kompiliert haben. Schon bei den ersten Versuchen damals trat dann der Fehler seltener auf, war aber dennoch nicht provozierbar - sondern weiterhin unmotiviert sporadisch.

Seit dem wir komplett auf Standard-Debian-Pakete für Apache2-MPM-worker und PHP5 gewechselt sind und dabei fastCGI wie oben genannt kompiliert haben, läuft es wie am Schnürchen. Wobei man gestehen muss, dass sich der Server langweilt.

Ich weiß, das klingt nicht nach Wissenschaft sondern nach Aberglauben und Hexerei. Aber wir können gern im direkten Kontakt mal die jeweilige config durchsprechen und vergleichen.
 
scheint ja ein debian/apache2/fcgid Problem zu sein. Hat es schon mal jemand mit einem Squeeze probiert? Mir gehen die Fehler langsam auch auf den Senkel...
 
Bei einem Projekt mit bis zu 550 Besuchern am Tag habe ich auch immer 500er bei fcgid + apache mpm worker + apc + php 5.2.x.

Ich habe mich heute nochmal intensiv mit der Dokumentation und den Parametern beschäftigt. Fcgid ist mittlerweile ein Apache-Projekt und recht gut dokumentiert - wenn man die Seite findet.

Da bin ich auf etwas interessantes gestossen:

By default, PHP FastCGI processes exit after handling 500 requests, and they may exit after this module has already connected to the application and sent the next request. When that occurs, an error will belogged and 500 Internal Server Error will be returned to the client.

=> http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#examples

Dort mal bei den "Special PHP considerations" lesen.

Es kann also sein, dass der Besucher immer Pech hat und gerade der 500. Request einer fcgid-Instanz ist - dann kriegt er einen 500er Error.

Je mehr Besucher und damit Requests, desto häufiger tritt das Problem also auf, da die 500 ja schneller erreicht sind.

Ich habe jetzt mal meine Einstellungen angepasst:

MaxRequestsPerProcess 500 # in der fcgid.con

PHP_FCGI_MAX_REQUESTS=10000
export PHP_FCGI_MAX_REQUESTS # im php-wrapper

Mal sehen, ob sich was tut, wenn nun bei mir

MaxRequestsPerProcess can be set to a value less than or equal to PHP_FCGI_MAX_REQUESTS to resolve the problem.

eingestellt ist und ausschliesslich PHP über den Tod eines Prozesses entscheidet.

Ich melde mich nochmal hier, in 1-2 Tagen sollte ich mehr wissen...
 
Ich glaube leider nicht, dass es helfen wird. Wir setzen auf unseren Servern auch den fcgid ein. Erlaubt sind 55000 Requests. Die Seiten sind zwar etwas stärker frewuentiert, trotzdem ist es keine Lösung die Requests noch weiter nach oben zu schrauben meiner Meinung nach.
Ich frage mich deshalb, wieso der fcgid Prozess nach <anzahl requests> Requests überhaupt noch Requests annimmt und nicht einfach sofort die Schotten dicht macht. Dann würde das Ganze einfach überhaupt nicht stattfinden. Klingt für mich leider nach schlecht programmierter Software.

Alleridngs muss ich auch sagen, dass es teilweise scheinbar Software abhängig ist, ob dieser Fehler auftritt. Bei einem Kunden mit 3-4k User pro Tag tritt der Fehler z.B. nicht mehr auf, seitdem er auf die neueste Version von Wordpress aktualisiert hat. :o
 
Bei mir ist es auch ein Wordpress Projekt. Habe da noch in der von WP generierten htaccess einige Direktiven geändert, aber es gibt trotzdem nach wie vor die 500er, garniert mit dieser Meldung in der error.log:

[warn] (103)Software caused connection abort: mod_fcgid: ap_pass_brigade failed in handle_request function

Wahrscheinlich hat es damit zu tun: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537922

Allerdings werden die 500er nicht angezeigt, für die Benutzer sieht alles normal aus und Beschwerden gab es auch noch keine.

Ich habe noch nicht auf die aktuelle WP-Version geupdatet, das ist auch das einzige WP-Projekt und ich habe somit keine Vergleichsmöglichkeiten. Da wir WPMU nutzen, möchte ich die 3er abwarten, wenn WPMU mit WP in der Stable (lol) verschmolzen wird.

Nun bin ich erstmal mit meinem Latein am Ende und kann nur auf fcgi 2.35 hoffen, dass in das nächste Debian Release Einzug findet. Oder dass sich mit der WP 3.0 was ändert.

Nachtrag: Eventuell kompiliere ich das aktuelle fcgid mal testweise in ein Lenny rein, die Apachejungs scheinen da einiges korrigiert zu haben...
 
Last edited by a moderator:
sorry, dass ich den Thread nach 4 Monaten wieder herauskrame. Ich wollte fragen, ob jemand weiter gekommen ist oder ein Workaround hat.

Mein Workaround: ich stelle auf apache_mod um und nach ein paar Wochen die Domain wieder auf fast_cgi

Aber eine schöne Lösung ist das nicht.
 
Ich bin hier immer noch dran. Ich habe eine neuere Version von mod_fcgid (2.3.5 statt 2.2 im Debian Repository) selbst kompiliert und werde diese bald auf einer Livekiste einsetzen. Vorher muss ich mich noch einmal mit den Parametern beschäftigen.

Melde mich dann wieder...
 
Hat sich hier schon etwas Neues ergeben? Ich habe einen ähnlichen Fehler, der ebenfalls sporadisch auftritt, weshalb ich auch auf diesen Thread gestoßen bin. Der Wortlaut in den Fehlermeldungen ist ähnlich. Hier ein Auszug nach einem Fehler 500 im Browser:

[Mon Nov 15 13:24:31 2010] [warn] [client 123.123.123.123] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server, referer: http://www.example.com/index.php
[Mon Nov 15 13:24:31 2010] [error] [client 123.123.123.123] Premature end of script headers: index.php, referer: http://www.example.com/index.php

Ich verwendete die sehr beliebte Extension "powermail" für TYPO3. Bei dem damit erzeugten Kontaktformular tritt dieser Fehler nur ab und zu auf. In den TYPO3-Foren konnte mir keiner helfen, da es in diesem Fall wohl eher etwas mit den verwendeten Paketen oder der Konfiguration zu tun hat.

Ich verwendete Debian Lenny und habe extra "libapache2-mod-fcgid" über die Backports installiert. Weiß jemand Rat?
 
Dann hast Du schon 2.3.5. Vor ein paar Tagen habe ich 2.3.6, das freigegeben wurde, in meine CentOS-Installationsskripte eingepflegt.

Da ich gerade von Debian > CentOS migriere, habe ich immer noch kein Produktivsystem mit CentOS und damit neueren Versionen als 2.2 unter Lenny aus dem Debian Repo am Start.

Allerdings habe ich mich intensiv mit der Konfiguration beschäftigt und bin schon ganz gespannt, wie fcgi unter CentOS und als aktuelle Version läuft.

Mal sehen, wann ich das endlich zeitlich hinbekomme, ich muss erst noch die Usermigrationsskripte für Systemuser, vHosts und MySQL schreiben...
 
Alles klar, wäre super wenn du hier über deine Erfahrungen berichtest, sobald du die Zeit findest. Momentan sehe ich mich fast gezwungen zu mod_php zu wechseln, was ich eher als Rückschritt sehe, allerdings funktioniert dort der Zugriff auf im Upload befindliche Dateien und deren Dateigröße. Das ist allerdings der einzige Vorzug, den ich bei mod_php sehe.

Viele Grüße aus Berlin.
 
Mache ich, ich will ja selbst diesen Fehler loswerden. Allerdings ist es durch den Distriwechsel nicht nur ein fcgid-Upgrade, sondern ich muss ja CentOS einmal komplett produktiv durchkonfigurieren & testen.

Das mit dem Uploadprogress lässt sich auch nicht über Workarounds herausfinden? Dateigrösse im Tmp-Ordner checken per AJAX?
 
Dass so ein Umstieg nicht von heute auf morgen gemacht ist, verstehe ich vollkommen.

Laut meinen eigenen Tests und den Aussagen in zahlreichen Foren kommst du bei einer FCGI-Konfiguration nicht an die Dateigröße der TMP-Datei. Vielleicht werde ich dieses Unterfangen auch noch mal in einer ruhigen Minute überprüfen oder nach einem Workaround schauen.
 
Ich habe an meinem Server (Ubuntu, Plesk) etwas herumprobiert und wollte per .htaccess die php-Dateien schützen. Das Ganze läuft mit Joomla, wobei alle unnötigen Pfade und Dateien in der Datei vhost.conf ausgesperrt sind. Nur die php-Dateien in den Unterordnern konnte ich nicht aussperren. Bei Joomla werden so gut wie alle Unterordner und Dateien durch /index.php includiert. Somit ist das Aufruffen der einzelnen Dateien in den unterordnern unnötig. Da ich auch vermeiden wollte, dass mir einer was hochlädt oder irgend ein Loch im System ausnutzt wollte ich alle Unterordner von joomla aussperren.

mod_fcgid ignoriert jedoch alle Angaben über php-Dateinen in den .htaccess dateien. trotz Spärre sind sie alle einzeln abruffbar. Trifft mod_fcgid auf eine php-Sperre im Pfad gibt es meistens den Fehler 500. Ich habe das Gefühl mod_fcgid kann mit .htaccess-Dateien im Bezug auf php, php-Sperren nicht richtig verrarbeiten. Einerseits ist das auch klar, da mod_fcgid nicht im apache sondern extern läuft.

Aber bisher habe ich auch nur Vermuttungen.
 
Das kann ich ehrlich gesagt nicht bestätigen, dass htaccess-Dateien im Allgemeinen Probleme bereiten. Fehler in der htaccess werden nur halt immer gleich mit einem Error 500 quittiert, was gerade am Anfang etwas nervig sein kann, allerdings gibt das Error-Log hier meist detailierte Infos, wo es klemmt.

Jedoch zurück zum Thema. Hat jemand eine Ahnung, wie man diese sporadischen Fehler in den Griff bekommt? Ich bin langsam echt am verzweifeln. Anfangs dachte ich, dass dies in Kombination mit dem verwendeten PHP-Opcode-Cache "eAccelerator" zu tun hat, aber Fehlanzeige.

Ich habe die FCGI-Lösung für eine solide, flexible und schnelle Lösung gehalten, weshalb ich sie bei vielen unserer betreuten Server einsetze. Dies schreckt mich allerdings ein wenig ab, weiterhin darauf zu bauen, obwohl mod_php für mich eigentlich nicht in Frage kommt, weil dort meines Wissens auch der Speicherverbrauch im Laufe der Zeit zunimmt oder ist das mittlerweile korrigiert worden? Wie auch immer, gerade bei der Verwendung mehrerer VHosts kann die FCGI-Konfiguration ihrer Vorzüge aufgrund der sicheren Trennung ausspielen.

Was mich mitterlweile etwas nachdenklich stimmt ist auch der Umstand, dass dieses scheinbar etwas fehlerbehaftete Paket einzug in Debian Lenny gefunden hat.
 
Back
Top