Webserver haben für verschiedene Anfragen und Prozesse Timeouts konfiguriert. Das verhindert, dass Clients, wie der Browser, im Fehlerfall (wenn die Serveranwendung hängt, feststeckt, abstürzt oder sonst etwas mit dem Server passiert, während der Client auf eine Antwort wartet) nicht endlos auf eine Antwort warten und blockieren. Manchmal dauert es aber länger bis eine Anfrage bearbeitet wurde oder ein Prozess abgeschlossen wurde. Dauert das länger als das konfigurierte Timeout zeigt der Client eine Fehlermeldung, der Prozess am Server läuft aber weiter, das kann zu inkonsistenten Datenständen, endlosen Wiederholungen von Aufgaben und anderen Problemen führen. Im besten Fall ist es einfach nur lästig. Diese Probleme löst man, indem man das Timeout einfach erhöht. In DSM ist vieles, was die Web Station, bzw. die Webserver, betrifft nicht einfach und Timeouts gehören dazu. In diesem Artikel beschreibe ich, wie Ihr die Timeouts je nach Situation erhöhen könnt.

Die Webserver am Synology NAS

Timeouts begegnet man auf Synology Geräten, wenn man dessen Webserver (Nginx und/oder Apache) nutzt um Webanwendungen (z.B. WordPress, Nextcloud) bereitzustellen. Vorgänge die Timeouts auslösen sind Installationsroutinen, Updates oder aber Uploads von besonders großen Dateien. Bevor ich zur Lösungsanleitung komme noch eine kurze Erklärung zum Synology NAS als Webserver.

Auch wenn man die Web Station bzw. die Webserver-Pakete gar nicht installiert läuft auf dem NAS bereits ein Webserver. Dieser stellt DSM und die Synology-Anwendungen bereit. Seit DSM 6 ist das Nginx. Installiert ihr die Web Station um eigene Webseiten oder Webanwendungen bereitzustellen habt Ihr die Wahl ob ihr ebenfalls Nginx verwendet, oder ob Ihr lieber den guten alten Apache wollt. Entscheidet ihr euch für letzteres läuft der Apache aber hinter dem Nginx, der als Proxy fungiert. Das gilt es dann ich Problemfällen zu berücksichtigen, da beide Ihre eigene Konfiguration haben.

Timeout erhöhen

Unter DSM 6 war das Timeout schnell erhöht, für Nginx musste einfach die Proxy.conf editiert werden und für den Apache einfach eine config-Datei erstellt werden. Unter DSM 7 gestaltet sich die Angelegenheit nicht schwieriger allerdings kniffliger. Das Timeout kann in der Proxy.conf nicht gesetzt werden, ein nginx -t (Test ob die Nginx-Konfiguration keine Fehler aufweist) weißt darauf hin dass das Timeout bereits an anderer Stelle gesetzt wurde. Da denkt man sich doch, gut gemacht Synology, ein Problem weniger um das man sich kümmern muss.
Tja, das gilt aber nur solange man keinen virtuellen Host konfiguriert, denn für diese gilt das gesetzte Timeout nicht. Die Proxy.conf wird in jeder anderen Konfigurationsdatei und auch in den Konfigurationsdateien für die virtuellen Hosts eingebunden, daher war die Änderung allgemein gültig. nginx -t weist nur auf das Duplikat in der Proxy.conf hin, aber nicht auf die ursprüngliche Stelle. Die ist aber schnell gefunden, nämlich in der nginx.conf. Das ganze sieht nach einer schnellen Lösung aus: raus mit dem Timeout aus der nginx.conf und rein damit in die Proxy.conf. nginx -t gibt seinen Segen und schon kann Nginx neu gestartet werden. Ein erneutes nginx -t offenbart dann aber ein Problem. Das Timeout steht wieder in der nginx.conf. Die wird nämlich beim Neustart des Nginx neu erstellt. Der Ursprung der Konfiguration ist ein anderer. Sucht man etwas weiter, findet man schnell die Konfigurationsdatei für die virtuellen Hosts, aber der Versuch dort, anstelle der Proxy.conf hinzuzufügen ist nur von kurzer Dauer, denn nach einem Neustart ist auch diese Datei wieder im Originalzustand.

Das liegt daran, dass Synology die eigentlichen Konfigurationsdateien für Nginx und Apache aus separaten Quelldateien immer neu generieren. Das hat wohl damit zu tun, wie Synology die Webserver-Konfiguration hinter dem grafischen Benutzerinterface der Web Station versteckt. Synology stellt sicher, dass der Betrieb von DSM und den Paketen so wenig wie möglich gestört werden kann. Unerfahrene Nutzer sollen so wenig wie möglich kaputt machen können. Für uns erfahrene Nutzer ist es dadurch aber oftmals schwierig Änderungen vorzunehmen.

Der Ursprung – und somit der Ort für eine persistierende Änderung – ist ein anderer, bzw. sind es mehrere Orte. Denn abhängig davon ob ihr Apache oder Nginx verwendet, müssen andere Anpassungen vorgenommen werden.

Mit DSM 7.1 und dem enthaltenen Update für die Web Station scheint man das Problem endlich in der GUI regeln zu wollen, allerdings ist das nur zur Hälfte gelungen. Mehr dazu weiter unten.

Nginx als Webserver

Nutzt ihr den Nginx als Webserver, habt ihr schon das längere Timeout von 3600 Sekunden. Das gilt aber, wie bereits erwähnt nicht, wenn Ihr einen vHost konfiguriert. Damit auch Anwendungen die über vHosts aufgerufen werden ein längeres Timeout haben, müsst ihr folgende Anpassungen vornehmen:

1. Verbindet euch per SSH (z.B. PuTTY) mit eurem NAS.
2. Führt die Änderungen als root durch. Gebt dazu sudo -i (Enter), dann das Passwort und erneut (Enter) ein, dann werden alle Befehle als root ausgeführt. Alternativ könnt ihr jeden Befehl mit sudo starten und das Passwort eingeben, wenn ihr dazu aufgefordert werdet.
3. Öffnet die Datei /etc/nginx/fastcgi.conf im Editor:

vi /etc/nginx/fastcgi.conf

4. Fügt am Ende der Datei die Zeile fastcgi_read_timeout 3600s; ein.
5. Speichert und schließt die Datei.
6. Testet zuerst die Nginx-Konfiguration, startet dann den Nginx neu, wenn der Test positiv ausfällt und testet die Konfig danach erneut:

nginx -t
synosystemctl restart nginx
nginx -t

Apache als Webserver

Nutzt ihr den Apache fungiert Nginx immer noch als Proxy und auch hier gilt das hohe Timeout für virtuelle Hosts nicht. Um dieses anzupassen ist folgendes notwendig:

1. Verbindet euch per SSH (z.B. PuTTY) mit eurem NAS.
2. Führt die Änderungen als root durch. Gebt dazu sudo -i (Enter), dann das Passwort und erneut (Enter) ein, dann werden alle Befehle als root ausgeführt. Alternativ könnt ihr jeden Befehl mit sudo starten und das Passwort eingeben, wenn ihr dazu aufgefordert werdet.
3. Öffnet die Datei /var/packages/WebStation/target/misc/VirtualHost-nginx.mustache im Editor.

vi /var/packages/WebStation/target/misc/VirtualHost-nginx.mustache

4. Fügt die Zeile proxy_read_timeout 3600s; im Block für Apache 2.2 bzw. Apache 2.4 unter include proxy.conf; ein. Führt die Änderung in jenem Block durch, der zur verwendeten Apache-Version passt. Ihr könnt die Zeile aber auch in beiden Blöcken einfügen.
5. Speichert und schließt die Datei.
6. Testet zuerst die Nginx-Konfiguration, startet dann den Nginx neu, wenn der Test positiv ausfällt und testet die Konfig danach erneut:

nginx -t
synosystemctl restart nginx
nginx -t

Das Timeout für den Proxy ist jetzt auch unter Verwendung von virtuellen Hosts erhöht. Jetzt kann es aber immer noch am Apache zum Timeout kommen. Das lässt sich, wie auch schon unter DSM 6 beheben:

1. Erstellt (als root) die Datei /usr/local/etc/apache2X/sites-enabled/user.conf

vi /usr/local/etc/apache2X/sites-enabled/user.conf

2. Fügt die Zeile TimeOut 3600 ein.
3. Speichert und schließt die Datei.
4. Startet den Apache neu.

Jetzt kommt es auch bei längeren Vorgängen zu keinen Timeouts mehr. Egal ob Ihr virtuelle Hosts/Reverse Proxys verwendet oder nicht und egal welchen Webserver ihr als HTTP-Backend-Server auswählt.

Nachtrag Timeout in der GUI

Mit 7.2 scheint das Timeout endlich über die GUI gesetzt werden zu können.

Setzt man unter DSM 7.1 das Timeout in der GUI bringt das leider nicht viel. Nach 60 Sekunden ist weiterhin Schluss. Ich habe den Hinweis erhalten, man müsse im PHP-Profil unter Kern die Variable default_socket_timeout umstellen (dort ist tatsächlich 60 eingetragen). Bringt aber auch nichts, zumindest nicht unter DSM 7.1. Ich habe dann dem Synology Support geschrieben. Leider hat es eine Weile gedauert bis ich klar machen konnte was mein Problem bzw. mein Anliegen ist. Als ich unter DSM 7 eine ähnliche Frage gestellt hatte habe ich prompt eine Antwort mit der oben stehenden Lösung bekommen. Diesmal hat es etwas länger gedauert. Die Antwort war wieder das editieren trotz Variablen in der GUI, noch dazu hat die mir zugesandte Lösung auch nicht funktioniert.
Was ist da also los? Hat Synology tatsächlich vergessen, dass Sie auch Apache als Backendserver anbieten? Oder hat sich einfach ein Fehler eingeschlichen? Bei den vielen Templates und Schnipsel, aus denen sich die eigentlichen Konfigurationsdateien zusammensetzen, wäre das nicht verwunderlich. Oder ist das ganze gar Absicht? Die Frage ist, wer soll da noch durchblicken, zumal in der GUI ja gar nicht ersichtlich ist wofür die Timeouts gelten.
Der Support war so nett mir einen Feature-Request zu erstellen. Leider bekommt man keinerlei Rückmeldung ob ein Feature-Request berücksichtigt wird oder nicht. Mein Tipp, erstellt ebenfalls einen Feature-Request, je mehr desto eher wird ein Feature berücksichtigt.