Linuxspicker

Für einige schlaflose Nächte sorgte ein beharrlicher 499 Error Code von Nginx bei der Ausführung eines php-Scripts ausgelöst durch Curl. Wenn es mal etwas länger dauerte, dann wurde die Ausführung genau nach 60 Sekunden gestoppt und der Cache-Server Varnish startete einen neuen Versuch, der aufgrund der gesetzten Sperre im php-Script fehlschlug.

Die 60 Sekunden deuten auf ein Timeout hin, aber alle Timeout-Parameter in Nginx, wie client_body_timeout, client_header_timeout, send_timeout, fastcgi_connect_timeout, fastcgi_send_timeout, fastcgi_read_timeout waren schon über die standardmäßigen 60 Sekunden hinaus erhöht worden und fielen somit heraus. Das betraf auch die Werte proxy_connect_timeout, proxy_send_timeout, proxy_read_timeout im Proxy-Modul des Frontend-Nginx. Auch die Limits für php-Scripts mit max_execution_time und max_input_time lagen ebenso über dem Standardwert. Den entscheidenden Hinweis gab – wie fast immer – ein Eintrag bei Stackoverflow, dass es sich bei dem 499er um ein Timeout auf der Clientseite handelt. Nginx sitzt hinter Varnish und daher konnte eigentlich nur Varnish in Frage kommen.

In Varnish gibt es wiederum mehrere Timeouts, die standardmäßig auf 60 Sekunden eingestellt sind. Jedoch waren für die Backends das first_byte_timeout und das between_bytes_timeout auf andere Werte als 60 Sekunden gesetzt worden und fielen darüber heraus. Blieben nur noch das idle_send_timeout und das pipe_timeout.

Da die Anfrage nach dem Script bei der Fehlersuche auf „pipe“ gesetzt wurde, fiel die Wahl am Ende auf das pipe_timeout. In der varnish.service-Datei daher den Parameter -p pipe_timeout=120 angefügt, ein systemctl daemon-reload hinterhergeschickt und in varnishadm den Parameter mittels param.set pipe_timeout 120 on-the-fly geändert. Nun darf das Script auch mal 120 Sekunden rödeln.