Apache 2.4 Timeouts seit Serverumgebung 0.331

  • Mir ist bei einer PHP Applikation, wo relativ große Dateien hochgeladen werden, mit 0.331 aufgefallen dass es hier zu Timeouts kommt, die es vorher definitiv nicht gab. Die relevanten Limits in der php.ini sind in Ordnung und habe ich mittels phpinfo() geprüft.


    In der httpd.conf (sowie natürlich httpd24.conf-template) habe ich

    Timeout 9500

    (also ein defintiiv ausreichender Wert)


    Das CPU Limit des zugrundeliegenden Angebots war auch stets sehr hoch, habe ich jetzt mittlerweile sogar testweise auf 5.000 erhöht.


    Im Einsatz ist derzeit cgiwrap.


    Dennoch, wenn ich einen http Upload mit 100MB mache (was vorher jahrelang kein Problem war), bricht dieser ab. Im error_log erscheint


    Code
    1. [Tue Apr 16 10:12:41.176261 2019] [cgid:error] [pid 1928] (70007)The timeout specified has expired: [client 78.132.xx.xxx:38429] AH01270: Error reading request entity data, referer: https://server.com/filetest.php

    Welches Limit könnte hier noch zuschlagen?

  • Mal testweise auf PHP-FPM umgestellt statt cgiwrap, Fehlermeldung äußerst ähnlich, was mich vermuten lässt das das Timeout an dem es scheitert Apache 2.4 seitig ist.


    Code
    1. [Tue Apr 16 10:45:35.412981 2019] [proxy_fcgi:error] [pid 8597] (70007)The timeout specified has expired: [client 78.132.xx.xxx:13920] AH01075: Error dispatching request to : (reading input brigade),
  • Neue Erkenntnis:
    Das Problem besteht nach einem testweisen Umschalten auf Apache 2.2 nicht.


    Ich stelle daher mal vorsichtig die Behauptung auf, dass die aktuell enthaltene Apache 2.4 Version die Timeout Anweisung in der httpd.conf ignoriert. Es ist kein generelles 2.4 Problem, da das System auch schon vorher auf dem 2.4er Zweig lief ohne diese Probleme. Es muss mit der aktuellen 2.4 Version 2.4.39 zu tun haben.

  • tbc233

    Hat den Titel des Themas von „CGI Timeouts seit Serverumgebung 0.331“ zu „Apache 2.4 Timeouts seit Serverumgebung 0.331“ geändert.
  • Ist ggf. irgendwo "ProxyTimeout" definiert? Wenn nicht, sollte ProxyTimeout = Timeout sein.

    Auf die schnelle habe ich im Changelog zu Version 2.4.39 kein Anhaltspunkt zu möglichen Änderungen gefunden.


    Wurde einmal die Zeit bis zum Timeout gemessen? Also lässt das Zeitfenster bis zum Timeout verlässlich reproduzieren?


    Ansonsten würde ich den Prozess einmal beobachten und mit strace versuchen zu debuggen.

  • ProxyTimeout wird nicht verwendet. Ich hab das Problem (und dessen Beseitigung durch Rückschritt auf 2.2) auf zwei unterschiedlichen Servern reproduziert. Auch die Zeit nach der abgebrochen wurde, war stets in etwa die selbe, nämlich 45 Sekunden (witzigerweise exakt der in meinem Fall auskommentierte Defaultwert "Timeout 45").

  • Hier ist definitiv was im Busch.


    Eben musste ich einen anderen Server, der mit all dem bisherigen nichts zu tun hat, auch auf 2.2. rückstufen. Ein Kunde mit einer eher langsamen Internetverbindung konnte in seinen Wordpress Blog keine 12MB Datei hochladen. War bei ihm mit Teamviewer drauf - wieder in etwa die 45 Sekunden, dann Abbruch mit selber Meldung im error_log.


    Auf Apache 2.2 umgestellt und alles funktioniert.

  • Ausgangslage Centos7 mit Umgebung 0.331 und aktiviertem Apache 2.4. Habe Fehler heute nachvollzogen auf 3 verschiedenen pd-admin Installationen bei 2 verschiedenen Providern / Rechenzentren.


    Es muss ein http Upload provoziert werden, der zwar seitens aller relevanten Limits (cgi Limits, PHP max_upload_sitze, PHP post_max_size, apache Timeout in der httpd.conf) funktionieren müsste, aber dennoch länger als 45 Sekunden (sagen wir sicherheitshalber 60 Sekunden) dauert. Wenn die Internetverbindung des Clients zum Server sehr sehr gut ist, wird man den Fehler vielleicht nie bemerken.


    Konkreter Aufbau (zum Teil im Zuge des Testens absurd hohe Werte nachfolgend, ändert aber nichts am stets reproduzierbarem Verhalten):


    1) apache Timeout 4500 Sekunden (ggf anpassen in /usr/local/pd-admin2/httpd-2.4/conf/httpd24.conf-template , dann /opt/pdadmin/bin/httpd_vhosts.pl ausführen)


    2) cgi CPU Zeit des zugrundeliegenden Angebots auf 600 Sekunden


    3) zuständige php.ini: PHP max_upload_sitze auf 1024M, post_max_size ebenso


    4) Einen http Upload durchführen, der wie gesagt länger als 60 Sekunden dauert. In meinem Fall hier hat meine Internetanbindung um die 30Mbit Upload, da reicht ein 120MB File um den Fehler zu reproduzieren. Kleinere Files gehen problemlos und produzieren den Fehler nicht.


    5) Den Upload zum Beispiel mit wordpress "Mediathek" durchführen falls grad bei der Hand. Falls nicht, kann auch mein PHP Testskript anbei verwendet werden, mit dem kann ich den Fehler genauso jederzeit reproduzieren.


    6) Der Upload bricht ab, im Browser erscheint ein Verbindungsfehler. Im error_log erscheint "The timeout specified has expired..... Error reading request entity data".


    Umschalten auf Apache 2.2: Alles funktioniert.

  • Hi,


    ich hatte das Problem auch gerade nach einem Update auf die 2.4.39 - jedoch immer nach exakt 20 Sekunden.

    das mod_reqtimeout Modul dürfte nach dem Update Vorrang haben gegenüber anderen Timeouts


    in meinem vhost habe ich dann gesetzt


    #RequestBody ein Stunde erlauben (3600s)

    RequestReadTimeout body=3600


    und schon war das Problem gefixt.. ;-)

  • Vielen Dank, das erleichtert mich direkt etwas. Bin aber unsicher was Du meinst mit "in meinem vhost habe ich gesetzt...". Die vhost Definitionen werden ja stets automatisch generiert und rausgeschrieben.


    Oder meintest Du global in der httpd.conf-template?

  • Sicherlich interessant für den Einen oder Anderen:


    Das Problem scheint mit Apache 2.4.39 einher zu gehen. Darin wurde mod_reqtimeout eingeführt, womit man Timeouts bei Handshakes konfigurieren kann. Bei einem Timeout kommt es zu den Log Einträgen von tbc233 . Beim Client kommt es zu einem 408 Fehler. Dies ist so auch in der Doku beschrieben:


    https://httpd.apache.org/docs/…t.html#requestreadtimeout


    Offenbar werden beim Apache 2.4.39 die Default-Werte nicht korrekt gesetzt. Dies wird mit Version 2.4.40 gefixt (bisher noch nicht veröffentlicht):


    https://svn.apache.org/repos/a…pd/branches/2.4.x/CHANGES


    Abhilfe schafft hier das Setzen des von TomLoader beschrieben Werts im Apache 2.4 Konfig Template:


    RequestReadTimeout body=3600


    Die Position ist egal. Ich habe den Wert über den TimeOut Werten gepackt.


    Reproduzierbar ist dies übrigens auch per WebFTP. Nach setzen von RequestReadTimeout klappte der Upload.


    Edit:


    Interessant wäre jetzt noch, ob tatsächlich ein Wert von 3600 benötigt wird oder ein geringerer Wert nicht auch ausreichend ist. Der Default-Wert ist wohl 20 Sekunden. Möglicherweise wird mit dem Fix in 2.4.40 der Wert korrekt gesetzt und der Eintrag im Template wird überflüssig.

  • Danke Dir für die Erkenntnisse. Der Wert von 3600 ist btw ziemlich sicher übertrieben, er wurde nur im Zuge des Testens so massiv erhöht. Ich stand ja am Anfang ohne jede Idee einer Ursache vor dem Problem und da klotzt man schon mal bei solchen Werten ;-)


    Da ich derzeit etwas Streß habe, bin ich noch nicht dazu gekommen Tomloaders Tipps auszuprobieren, zumal ich es durch apache2.2 ja mal entschärfen konnte. Ich werde wohl weitere Versionen mal abwarten.

  • Und noch ein Nachtrag, da ich weiter getestet hatte:


    Das Problem lässt sich ebenfalls durch zwei andere Anpassungen beheben:


    1. Das Modul mod_reqtimeout im Konfig Template auskommentieren.


    2. Den Default Wert für RequestReadTimeout richtig setzen:

    Code
    1. RequestReadTimeout body=20,MinRate=500

    zur Erklärung: Es erfolgt ein Timeout nach 20 Sekunden. Werden jedoch Daten empfangen, erhöht sich der Timeout. Bei dem Default Wert je 500byte um 1 Sekunde.

    Dadurch werden idle Verbindungen nach 20 Sekunden beendet, bei Uploads bleibt die Verbindung bestehen.


    Ich habe bei mir Punkt 2 umgesetzt, womit alles wieder korrekt funktioniert.


    tbc233 mit den 3600 meinte ich den Wert im Beispiel von TomLoader. Den Wert empfinde ich als zu hoch, da Timeouts ja durchaus sinnvoll sind. Zu hohe Werte können sich negativ auswirken bzw. machen solche Direktiven unwirksam und sinnfrei.

  • Hello,


    I'm a french sysadmin and I found this thread in Google after hours of search.

    I'm facing the same issue: reading input brigade. It happens only for a few requests: around 50 errors for +500 000 requests per day.


    I'm not using pd-admin, my stack is:

    - HAProxy

    - Apache 2.4.38 (compiled from source) with mod_proxy_fcgi (ProxyPassMatch or SetHandler)

    - 3 FPM: 5.6, 7.1, 7.3 in socket mode


    The issue happens:

    - almost only when users are sending POST request (with file or not).

    - for all FPM

    - for all kind of applications (legacy code, symfony app, wordpress)


    The issue triggers:

    - HTTP 408 code in Apache logs

    - 408 or -1 code in HAProxy logs


    I am currently trying your fix (RequestReadTimeout) and waiting for a feedback from my customers.


    Thank you for your information about this issue, I had no more ideas to solve it.

  • It looks like the same problem. You should check if setting RequestReadTimeout in your Apache config solves problem.

    Unfortunately it will be difficult to reproduce the same error as the pd-admin server environment might be built different than your setup.

    Also it would be helpful to have more detailed information, like the exact error message from your logs. Or the configuration of your Apache.

  • Here is my logs:

    Code: error.log
    1. [Thu May 23 16:58:10.526675 2019] [proxy_fcgi:error] [pid 1143:tid 140238324197120] (104)Connection reset by peer: [client ********:0] AH01075: Error dispatching request to : (reading input brigade), referer: *******
    2. [Thu May 23 17:27:30.429678 2019] [proxy_fcgi:error] [pid 1233:tid 140238506522368] (70007)The timeout specified has expired: [client ********:0] AH01075: Error dispatching request to : (reading input brigade), referer: *******

    My Apache configuration has nothing special, here is the relevant parts:

    If the RequestReadTimeout is not working, I will test if the issue remains with a Apache 2.2 instance or wait for 2.4.40 :(

  • After a few weeks, the issue seems to be resolved.


    Except for one customer, he was experiencing the same kind of issue (408 / client timeout), but it was an issue with HTTPS. It seems that his Windows 7 has some issues with HTTPS in all web browsers, after an upgrade to W10, the issue disappeared.


    Thanks a lot for your help !