Watchdog-Timer unter Linux: Hardware- und Software-Watchdogs richtig einsetzen

1. Was ein Watchdog-Timer eigentlich macht

Das Grundprinzip eines Watchdog-Timers ist bewusst simpel gehalten: Ein Timer zählt kontinuierlich herunter, und eine überwachende Instanz, meist der Kernel oder ein Daemon im Userspace, muss den Timer in regelmäßigen Abständen zurücksetzen, umgangssprachlich als Füttern bezeichnet. Bleibt diese Bestätigung aus, weil der überwachte Prozess hängt, abgestürzt ist oder in einer Endlosschleife feststeckt, löst der Timer beim Erreichen von Null automatisch einen harten Reset des Systems aus.

Diese Einfachheit ist zugleich die Stärke des Konzepts: Ein Watchdog trifft keine komplexe Diagnose darüber, warum ein System nicht reagiert, er reagiert lediglich auf das Ausbleiben der erwarteten Bestätigung. Genau dieser reduzierte Funktionsumfang macht ihn robust genug, um selbst dann noch zu funktionieren, wenn praktisch alle anderen Komponenten des Systems bereits versagt haben.

2. Der Hardware-Watchdog unter /dev/watchdog

Server-Hauptplatinen bringen häufig einen eigenen Hardware-Watchdog-Chip mit, etwa als Teil des iTCO-Chipsatzes bei Intel-Plattformen oder als Bestandteil eines IPMI-Controllers bei dedizierten Server-Boards. Der Kernel-Treiber für diesen Chip stellt das Gerät /dev/watchdog bereit, über das ein Userspace-Prozess den Timer per write()-Aufruf regelmäßig zurücksetzt.

Der entscheidende Vorteil eines Hardware-Watchdogs ist seine Unabhängigkeit vom eigentlichen Betriebssystem: Selbst wenn der Kernel vollständig eingefroren ist und keinerlei Code mehr ausführt, läuft der Timer auf der Hauptplatine unabhängig weiter und löst nach Ablauf einen echten Hardware-Reset aus, unabhängig davon, ob das Betriebssystem überhaupt noch in der Lage wäre, selbst einen Neustart einzuleiten.

# Vorhandenen Hardware Watchdog Treiber identifizieren
ls -la /dev/watchdog*
cat /sys/class/watchdog/watchdog0/identity

# Aktuelles Timeout des Hardware Watchdogs auslesen
cat /sys/class/watchdog/watchdog0/timeout

3. Software-Watchdog gegenüber Hardware-Watchdog

Fehlt dedizierte Watchdog-Hardware, etwa in virtuellen Maschinen ohne durchgereichten Chipsatz, springt das Kernel-Modul softdog ein und emuliert einen Watchdog rein in Software. Da dieser Timer selbst Teil des Kernels ist, schützt er zuverlässig gegen hängende Userspace-Prozesse, aber nicht gegen einen tatsächlichen Kernel-Panic oder eine echte Kernel-Ebenen-Blockade, weil der emulierte Timer in diesem Fall selbst nicht mehr laufen kann.

In Cloud-Umgebungen mit virtuellen Maschinen ist die Situation gemischt: Manche Hypervisoren, etwa KVM mit dem i6300esb-Emulator, reichen einen virtuellen Hardware-Watchdog an den Gast durch, der sich fast identisch zu echter Hardware verhält. Andere Cloud-Provider bieten stattdessen eigene, außerhalb der VM laufende Health-Checks an, die eine ähnliche Rolle übernehmen, aber anders konfiguriert werden müssen als ein klassischer Linux-Watchdog.

4. Der systemd-integrierte Watchdog

systemd selbst kann als Watchdog-Client fungieren und übernimmt dabei das regelmäßige Füttern von /dev/watchdog, sobald in /etc/systemd/system.conf die Option RuntimeWatchdogSec gesetzt ist. Damit entfällt die Notwendigkeit, einen separaten klassischen watchdog-Daemon zu betreiben, weil PID 1 diese Aufgabe ohnehin bereits zentral übernimmt.

Zusätzlich kennt systemd einen zweiten, unabhängigen Watchdog-Mechanismus namens ShutdownWatchdogSec, der speziell den Herunterfahrvorgang selbst absichert. Bleibt ein Server während des Shutdowns hängen, etwa wegen eines Dienstes, der sich nicht sauber beenden lässt, löst dieser separate Timer nach Ablauf einen erzwungenen Reset aus, statt den Server unbegrenzt im Shutdown-Zustand verharren zu lassen.

# /etc/systemd/system.conf
[Manager]
RuntimeWatchdogSec=30s
ShutdownWatchdogSec=10min

5. WatchdogSec in einzelnen systemd-Units konfigurieren

Neben dem systemweiten Hardware-Watchdog unterstützt systemd auch einen anwendungsspezifischen Watchdog-Mechanismus über die Direktive WatchdogSec in einer einzelnen Service-Unit. Der überwachte Dienst muss dafür über die sd_notify Schnittstelle regelmäßig WATCHDOG=1 an systemd melden, üblicherweise über die libsystemd Bibliothek oder ein entsprechendes Sprach-Binding.

Bleibt diese Bestätigung länger als die konfigurierte Zeitspanne aus, betrachtet systemd den Dienst als hängend und wendet die in WatchdogSignal und FailureAction konfigurierte Reaktion an, üblicherweise einen Neustart des Dienstes über die reguläre Restart= Logik. Dieser Mechanismus fängt damit auch Anwendungs-Hänger ab, die keinen Kernel-Watchdog auslösen würden, weil der Prozess selbst technisch noch läuft, aber intern nicht mehr auf Anfragen reagiert.

# /etc/systemd/system/myapp.service
[Service]
ExecStart=/usr/local/bin/myapp
WatchdogSec=15s
Restart=on-watchdog

6. Der klassische watchdog-Daemon und /etc/watchdog.conf

Vor der breiten Verfügbarkeit des systemd-integrierten Watchdogs übernahm das eigenständige Paket watchdog diese Aufgabe, konfiguriert über /etc/watchdog.conf. Dieser Daemon bietet zusätzlich zur reinen Timer-Bestätigung eigene Prüfungen an, etwa Grenzwerte für Load Average, freien Arbeitsspeicher oder die Erreichbarkeit konfigurierter Testdateien, und löst bereits bei Überschreitung dieser Schwellen einen Neustart aus, unabhängig vom eigentlichen Hardware-Timeout.

Für die meisten modernen Setups mit aktuellem systemd ist der integrierte Watchdog-Mechanismus die einfachere Wahl, weil er ohne zusätzliches Paket auskommt und sich sauber mit der übrigen Unit-Konfiguration verzahnt. Der klassische Daemon bleibt vor allem dort relevant, wo sehr ältere Systeme oder spezielle, über den reinen Watchdog hinausgehende Zusatzprüfungen benötigt werden.

7. Praxisfall: Unbeaufsichtigten Server automatisch neustarten lassen

Für einen Magento-Hosting-Server ohne physische Vor-Ort-Betreuung außerhalb der Geschäftszeiten ist die Kombination aus Hardware-Watchdog und systemd-Integration die robusteste Lösung. Der Hardware-Watchdog fängt den Fall eines vollständig eingefrorenen Kernels ab, während WatchdogSec in kritischen Service-Units, etwa für PHP-FPM oder Nginx, Anwendungs-Hänger erkennt, die den Kernel selbst gar nicht betreffen.

Wichtig ist ein realistisches Timeout: Ein zu kurzes RuntimeWatchdogSec löst bei kurzen, aber harmlosen Lastspitzen unnötige Neustarts aus, während ein zu langes Timeout im Ernstfall die Ausfallzeit unnötig verlängert. Ein Startwert von 30 bis 60 Sekunden für den Hardware-Watchdog und 15 bis 30 Sekunden für kritische Anwendungs-Watchdogs hat sich in der Praxis für die meisten Webserver-Workloads bewährt.

# Watchdog Status und aktuell konfiguriertes Timeout pruefen
systemctl show -p RuntimeWatchdogUSec
wdctl /dev/watchdog

8. Watchdog-Konfiguration testen, ohne einen Produktionsausfall zu riskieren

Ein Watchdog, der nie getestet wurde, ist im Ernstfall ein unbekanntes Risiko. Auf einer separaten Testmaschine oder in einer VM lässt sich ein tatsächlicher Hänger simulieren, etwa durch einen bewusst blockierenden Kernel-Modul-Aufruf oder durch das Anhalten des systemd-Prozesses selbst mit SIGSTOP, um zu prüfen, ob der konfigurierte Neustart tatsächlich auslöst.

Für die Anwendungs-Ebene lässt sich WatchdogSec ebenso gezielt testen, indem der überwachte Dienst kurzzeitig blockiert wird, etwa durch eine künstliche Endlosschleife in einer Testversion. Erst wenn der beobachtete Neustart innerhalb der erwarteten Zeitspanne tatsächlich eintritt, sollte die Konfiguration als produktionsreif betrachtet werden, da theoretisch korrekte Konfiguration und tatsächliches Verhalten durchaus voneinander abweichen können.

9. Best Practices und typische Fallstricke

Ein häufiger Fehler ist die Annahme, ein Software-Watchdog schütze auch gegen einen echten Kernel-Panic. Das stimmt nur bedingt: Ein Kernel-Panic löst in den meisten Konfigurationen bereits eigenständig über kernel.panic in sysctl einen Neustart aus, während ein Watchdog primär gegen stille Hänger schützt, bei denen der Kernel technisch läuft, aber nicht mehr reagiert.

Cloud-Provider unterscheiden sich stark in ihrer Watchdog-Unterstützung: Manche reichen einen virtuellen Hardware-Watchdog vollständig durch, andere blockieren den Zugriff auf /dev/watchdog in ihren Standard-Images komplett. Vor dem produktiven Einsatz lohnt sich deshalb ein expliziter Test in der jeweiligen Zielumgebung, statt sich auf die Konfiguration eines On-Premises-Servers eins zu eins zu verlassen.

10. Zusammenfassung

11. FAQ: Watchdog-Timer