Apache2 FastCGI Scripte brechen nach 40 Sekunden ab

2010-01-24 - kostaki 19 Kommentare »

Das Problem ist das länger laufende Scripte immer nach exakt 40 Sekunden abbrechen. Zum Beispiel bei längeren MySQL Befehlen in phpmyadmin hat es mich genervt. Diese musste ich schon oft auf der Console ausführen. Das erhöhen des IPCCommTimeout in der Config hat mir leider nicht geholfen, da es aktuell einen Bug gibt. Die Werte aus der Config werden in den vhost Containern wieder zurück gesetzt und das passiert für das ganze System. Die Lösung war dann recht einfach. Man lädt die Config in jedem vhost. Nicht nur in einem, sondern wirklich in jedem!

<VirtualHost *:80>
    Include /etc/apache2/mods-available/fcgid.conf
</VirtualHost>

Nachdem man dies in jeden vhost eingetragen hat und man den IPCCommTimeout in der Config erhöht hat, muss man noch den apache neu starten.

$ apache2ctl configtest
Syntax OK
$ /etc/init.d/apache2 restart

Testen

Zum testen hier ein kleines PHP Script, das für 120 Sekunden schläft.

<?php
echo 'start<br />';
$sleep = 120;
echo $sleep . ' sleep<br />';
sleep($sleep);
echo 'end<br />';
?>

Ruft man es ohne diese Anpassungen auf, sollte nach 40 Sekunden ein Timeout kommen und man sieht einen 500 Fehler. In den Logfiles landen dann diese Fehler:

[warn] mod_fcgid: read data timeout in 40 seconds
[error] [client 111.111.2.111] Premature end of script headers: test.php
[warn] mod_fcgid: read data timeout in 40 seconds
[error] [client 111.111.2.111] Premature end of script headers: test.php
[warn] mod_fcgid: read data timeout in 40 seconds
[error] [client 111.111.2.111] Premature end of script headers: test.php
[warn] mod_fcgid: read data timeout in 40 seconds
[error] [client 111.111.2.111] Premature end of script headers: test.php
[warn] mod_fcgid: read data timeout in 40 seconds

Nach dem man den IPCCommTimeout in der Config hoch gesetzt hat und sie in jedem vhost geladen hat, sollte das Script durchlaufen. Ich schätze außerdem das dies nicht nur für den IPCCommTimeout aus der Config gilt, sondern auch bei anderen Settings. Hatte ich leider noch keine Zeit zu testen, wenn da jemand mehr weiß bitte hinterlasst mir ein Kommentar.

Related Links

Ähnliche Artikel

  1. 19 Kommentare

  2. Commander1024
    schrieb am 17.03.2010 um 16:05 Uhr

    Komisches ding, der Parameter MaxProcessCount wurd auch ohne separaten Include im VHost ausgewertet, aber das 40Sek Timeout Problem hat Deine Methode behoben, jetzt meckert der wordpress beim Update auch nicht mehr. Thnx.

  3. Mark Breyer
    schrieb am 01.04.2010 um 15:05 Uhr

    Hab selbst lange nach dem Problem gesucht, aber auf den include bin ich nicht gekommen. Hab es seit ca. einer Woche in Betrieb und seither keine Probleme mehr. Vielen Dank.

  4. Flo
    schrieb am 10.04.2010 um 10:31 Uhr

    Ich kämpfe auch seit langem mit dem 40 Sekunden timeout. Bei mir habe ich IPCCommTimeout auf 360 gesetzt, der Server scheint die Einstellungen auch geschluckt zu haben, rufe ich über PHP den 120 Sekunden sleep auf, beendet das Programm und es gibt kein Timeout. Schaue ich jeodch in die Server logs taucht hier das Timeout 40 Problem fast jeden Tag auf, hervogerufen durch scripts die per cronjob gestartet werden.
    Das verrückte daran jedoch ist, dass die cronjobs mit GET ‘url..’ augerufen werden, also nichts anderes als würde ich das Script per Browser aufrufen.
    Hat jemand eine Idee woran das liegen könnte?

  5. Flo
    schrieb am 10.04.2010 um 10:50 Uhr

    Ich habe noch einen Vhost Eintrag gefunden indem kein inlude der fcgid.conf enthalten war. Das hatte zwar nicht den Vhost betroffen in dem ich das Problem habe, aber kann es sein, dass dieser auch wenn hier gar keine Einstellungen zu fcgid festgelegt wurden die anderen dann auch zurücksetzt und es dann immer ein hin und her der fcgid einstellungen der anderen Vhost und diesem ist?

  6. kostaki
    schrieb am 10.04.2010 um 10:54 Uhr

    Ich glaube schon. Geh am besten davon aus und trage die fcgid.conf in jeden vhost ein. Sollte keinen Negativen Effekt haben, aber dieser Bug scheint sich darauf zurück zu führen lassen. Seltsam ist es natürlich schon das es bei dir Teilweise funktioniert… Bei mir war es entweder immer oder gar nicht mehr. Hast du mal das Testscript per Crontab aufgerufen?

  7. Der Adminblogger
    schrieb am 21.04.2010 um 15:11 Uhr

    Die “Lösung” von Dir funktioniert leider nicht.

    Es ist richtig, dass beim Eintragen von IPCCommTimeout in den VirtualHost (oder bei dir das Inkludieren der fcgid.conf) der erste Request sich an diese Einstellung hält.

    Ein IPCCommTimeout 200 z.b. bewirkt bei meinem Skript sleep(300); einen Abbruch nach 200 Sekunden. So steht es auch im error_log.

    Anschließend wird der PHP-Prozess von Apache gekillt.

    Rufe ich die Datei jetzt erneut auf, forkt Apache einen neuen PHP-Prozess, der allerdings wieder den einkompilierten Default-Wert von 40 Sekunden benutzt.

    Eine Lösung mit dem libapache2-mod-fcgid aus lenny ist leider nicht in Sicht.

    Gruß,
    Marcel.

  8. kostaki
    schrieb am 21.04.2010 um 16:58 Uhr

    Hi,

    bist du dir sicher das du es in jeden Vhost eingetragen hast? Ich hab es gerade noch mal auf einem seit 2 Wochen laufenden Apache getestet und bei mir kommt dieser Fehler nicht vor. Das Script schläft 200 Sekunden und gibt mir dann die Ausgabe aus.

    Gruß

    kostaki

  9. Der Adminblogger
    schrieb am 22.04.2010 um 11:35 Uhr

    Hi kostaki,

    ich muss mich korrigieren – Du hast recht, es funktioniert.

    Ich hatte es nur in einem Vhost drin und sobald einer der anderen Vhosts aufgerufen wurde, sind die Werte auf die Defaults zurückgesetzt worden.

    Laut mehreren Berichten ist es auch unbedingt erforderlich, dass DefaultMinClassProcessCount in jeden Vhost gesetzt wird, sonst haben die Timeouts keine Wirkung (http://sourceforge.net/mailarchive/message.php?msg_name=20070516151638.13781e84.listen%40mjh.name)

    Nachdem ich dann noch über https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-fcgid/+bug/273388 gestolpert bin, habe ich es dann tatsächlich in *jeden* Vhost eingetragen und es funktioniert.

    Laut http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/README-FCGID?view=log haben neuere Versionen von mod_fcgid nicht mehr das Problem, die Bugs sind offenbar gefixt worden.

    Gruß,
    Marcel.

  10. kostaki
    schrieb am 24.04.2010 um 10:17 Uhr

    Schön das es nun funktioniert. Den Release von Squeeze kann ich auch kaum erwarten, aber bis dahin kann man sich mit dieser Lösung behelfen.

    Gruß

    kostaki

  11. webby
    schrieb am 08.07.2010 um 14:54 Uhr

    Hallo, auch bei mir brechen einige skripte nach 40 sek ab und ich erhalte die selbe fehlermeldung im Log.
    Ich habe keine “fcgi.conf” datei die ich in der VirtualHost includieren könnte.

    Die entsprechende Konfiguration habe ich in httpd.conf reingeschrieben:

    AddHandler fcgid-script .fcgi
    SocketPath /tmp/fcgid_sock
    IdleTimeout 3600
    DefaultMinClassProcessCount 100
    IPCConnectTimeout 400

    Ist ein Include trotzdem noch notwendig damit ich das Problem mit den 40 sekunden lösen kann?

    lg
    Webby

  12. webby
    schrieb am 08.07.2010 um 15:16 Uhr

    offenbar werden die sptizen klammern hier “gefressen”
    am beginn der oben genannten Zeilen in httpd.conf steht noch:

    IfModule mod_fcgid.c
    bzw. am ende
    IfModule

  13. kostaki
    schrieb am 08.07.2010 um 18:23 Uhr

    Die fcgid Settings mussen nur in jedem vhost stehen. Ob das durch einen Include gemacht wird oder direkt eingetragen wird ist egal, es muss nur wirklich in jedem vhost passieren! Wenn man eh immer die gleichen haben will, bietet sich der Include natürlich an.

  14. Erwin
    schrieb am 07.11.2010 um 16:48 Uhr

    Hurra !!!

    Dieses Problem nervt mich seit ewigen Zeiten (fast 2Jahre)

    Hatte mich damit abgefunden – aber immo kam es grad wieder hoch und ich hab Onkel G00gle gefragt und bämm – schon isses Geschichte. :-)

    Made my day !!!

  15. Pangu
    schrieb am 01.02.2012 um 18:26 Uhr

    Auf Debian Squeeze 64bit mit Apache 2.2.16 und php 5.3.3 mit fcgid und suexec funzt das nicht. Wie muss denn die /etc/apache2/mods-available/fcgid.conf aussehen, bitte postet mal den Inhalt hier rein. Ich verwende wegen einer Apache-Sicherheitslücke Files Match in meiner vHost-Konfig. Meine vHost sieht so aus, und ich krieg immer noch 500er Fehler mit dem hier geposteteten Script-Test zum Checken des Timeouts.

    ServerName defaultsite.localhost
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/defaultsite
    SuexecUserGroup phpfcgiuser phpfcgiuser

    Options FollowSymLinks
    AllowOverride None

    FCGIWrapper /var/www/conf/fcgi-starter .php

    SetHandler fcgid-script

    Options +ExecCGI -Indexes
    Order allow,deny
    allow from all
    AllowOverride All

    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

    AllowOverride None
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    Order allow,deny
    Allow from all

  16. Pangu
    schrieb am 01.02.2012 um 18:42 Uhr

    OH MANN! Ich hab den Fehler!! Hab vom Beitrag von (webby) weiter oben abgeschrieben :) und der hatte drinstehen “IPCConnectTimeOut” dabei heißt es richtigerweise “IPCCommTimeout 400″ ;-)

    jetzt klappt’s auch mit dem test-script. DANKE!

  17. Philipp Klaus
    schrieb am 26.04.2012 um 17:16 Uhr

    Hallo Pangu, danke für den Hinweis! Ich hatte es auch falsch abgeschrieben und wurde fast verrückt!
    Gruß Philipp

  18. Pangu
    schrieb am 02.08.2012 um 11:20 Uhr

    Übrigens: mit den neueren Versionen geht das ganz einfach, und zwar gibts dafür die FCGID Direktive “FcgidIOTimeout”

    Beschreibung und Erklärung:
    http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidiotimeout

    Um also das Timeout zu erhöhen, könnt ihr einfach direkt in /etc/apache2/mods-available/fcgid.conf die Zeile hinzufügen:

    FcgidIOTimeout 300

    Das erhöht dann den Timeout von den standardmässigen 40 sekunden auf 300 Sekunden.

    Viele Grüße,
    Pangu

  1. Trackback(s)

  2. Apr 1, 2010:Lösung: Apache2 FastCGI Scripte brechen nach 40 Sekunden ab | BlogTorrent
  3. Mai 31, 2012:[fix] mod_fcgid: HTTP request length xyz (so far) exceeds MaxRequestLen (131072)

Kommentar schreiben

*

*

RSS | Design by Bob