HAPPYTEC.at :: Blog :: Kurz notiert: Wenn Munin-Node beim Starten ins Timeout läuft

Nach einem Upgrade von Debian Stretch auf Buster und direkt weiter auf Debian Bullseye, sah ich mich am Wochenende mit einem völlig neuen Problem konfrontiert: Das (Neu-) Starten des Munin-Nodes dauerte ewig und lief sogar in ein Timeout. Systemd versuchte danach quasi im Minutentakt, den Dienst hoch zu bringen, was immer wieder scheiterte. Grafiken dieses Nodes wurden dementsprechend keine mehr generiert.

Die grundlegende Ursache: Ich verwende auf diesem Host sehr viele snmp_* Plugins, von denen aber einige Hosts nicht 24/7 laufen. Beim Starten von munin-node werden alle Plugins einmal mit "config" initialisiert. Das dauert so schon relativ lange, aber noch länger, wenn bei allen Hosts, die offline sind, jeweils auf ein Timeout gewartet werden muss. Wenn das insgesamt länger dauert, als Systemd bereit ist zu warten, bekommt man ein Problem. Durch den andauernden Neustart des Dienstes kann dieser die Initialisierung niemals vollenden und steht nicht zur Verfügung.

Man kann das Timeout der snmp-Plugins zwar schön mittels plugin-conf.d herabsetzen, aber bei hunderten Einzelaufrufen summiert es sich trotzdem entsprechend, wenn man nicht Dutzende parallele Prozesse zulässt:

Code:

[snmp_*]
timeout 5

Die simple Lösung: Glücklicherweise muss man Systemd nur beibringen, dass er länger warten soll...

Code:

systemctl edit munin-node.service

Im darauffolgenden Editor ändert man den Wert für TimeoutStartSec:

Code:

[Service]
TimeoutStartSec=900

Niedrigere Werte funktionieren natürlich auch, ich wollte aber auf Nummer sicher gehen.

Bleibt nur noch das Problem, dass ein manueller (Neu-) Start auf der Kommandozeile durch --foreground immer noch ewig dauert. Die korrekte Lösung hierfür findet man mit dem Argument --no-block:

Code:

systemctl restart --no-block munin-node.service

In diesem Fall sollte man den Status später aber nochmals kontrollieren oder einen Blick ins Journal bzw. Logfile werfen.