Hardware-Watchdog-Timer & Autonome Kernel-Wiederherstellung

Unbeaufsichtigte Edge-Geräte in abgelegenen Trafostationen, Solarparks oder Schaltschränken müssen dauerhaft und ohne menschlichen Eingriff laufen. Kommt es durch einen unerwarteten Linux-Kernel-Deadlock, Speicherlecks oder Deadlocks in Treibern zum Einfrieren des Systems, kann kein Servicetechniker erst auf eine Leiter steigen, um den Stromschalter manuell aus- und wieder einzuschalten.

Die Broadcom BCM2711 und BCM2712 SoCs verfügen über einen Hardware-Watchdog-Timer (WDT), der direkt in das Silizium des Prozessors integriert ist. Versäumt es das Betriebssystem, diesen Hardware-Timer innerhalb eines vorgegebenen Zeitfensters zurückzusetzen („zu füttern“), löst der Silizium-Baustein eigenständig einen harten elektrischen Kaltstart (Hardware-Reset) aus. Das System startet neu und nimmt die Messwerterfassung wieder auf.

1. Silizium-Mechanik: Software-Watchdogs vs. Hardware-WDT

Der Unterschied zwischen reinen Software-Überwachungsskripten und einem echten Silizium-Hardware-Timer ist der Schlüssel zu Hochverfügbarkeit:

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    subgraph SoftwareMonitor["Software-Daemon (Versagt bei Deadlocks)"]
        direction TB
        S1["Ueberwachungs-Skript"] -->|Prueft Dienste| S2["Prozess-Tabelle"]
        S2 -->|Kernel-Deadlock / OOM| S3["Skript haengt / keine CPU"]
        S3 ==> HANG["Geraet friert dauerhaft ein<br/>(Techniker-Einsatz noetig)"]
    end

    subgraph HardwareWDT["Silizium-Watchdog (Broadcom WDT)"]
        direction TB
        W1["Silizium 15s Timer-Register"]
        W2["Systemd / Watchdog-Daemon"] -->|Heartbeat Ping| W1
        DEADLOCK["Kernel Panic / Totalabsturz"] -.->|Verhindert Heartbeat| W2
        W1 -->|Timer erreicht 0s| W3["Hardware RESET auf LOW"]
        W3 ==> REBOOT["Elektrischer Kaltstart.<br/>System heilt sich selbst!"]
    end

    SoftwareMonitor -->|"Hardware-Loesung"| HardwareWDT

Warum reine Software-Watchdogs versagen

Gerät der Linux-Kernel in eine Out-of-Memory (OOM)-Schleife, einen Interrupt-Sturm oder blockiert ein Treiber eine Kernel-Sperre (Spinlock): 1. Friert der Kernel-Scheduler ein oder verharrt in Endlosschleifen. 2. Userspace-Prozesse – darunter Cronjobs, Docker-Healthchecks und Python-Skripte – erhalten keinerlei CPU-Rechenzeit mehr. 3. Der Raspberry Pi verbleibt im Zustand eines nicht erreichbaren "Zombies", bis jemand physisch den Strom trennt.

Wie der Broadcom Hardware-Watchdog arbeitet

Der Broadcom-Watchdog (bcm2835_wdt) ist ein eigenständiges Hardware-Peripheriemodul im Chip, das von einem separaten On-Chip-Oszillator getaktet wird. Er zählt kontinuierlich von einem programmierten Maximalwert (bei Broadcom maximal 15 Sekunden) herunter. Solange Linux gesund läuft, schreibt ein Hintergrunddienst in festen Intervallen ein Lebenszeichen an /dev/watchdog. Friert der Kernel ein, bleibt das Signal aus, der Zähler schlägt bei 0 auf und die interne Schaltung erzwingt einen sofortigen Hardware-Neustart.

2. Kernel-Aktivierung & Gerätedatei prüfen

Auf modernen Kerneln von Raspberry Pi OS Bookworm (Linux 6.x) ist der Watchdog-Treiber im Kernel enthalten, muss jedoch in der Firmware-Konfiguration per Device Tree aktiviert werden.

Schritt 1: Watchdog in config.txt aktivieren

Datei /boot/firmware/config.txt öffnen:

sudo nano /boot/firmware/config.txt

Folgenden Eintrag prüfen oder ergänzen:

# Broadcom Hardware-Watchdog-Timer aktivieren
dtparam=watchdog=on

Speichern und das System neu starten:

sudo reboot

Schritt 2: Gerätedatei kontrollieren

Prüfen, ob die Gerätedateien vom Kernel bereitgestellt werden:

ls -l /dev/watchdog*

Erwartete Ausgabe:

crw------- 1 root root  10, 130 ... /dev/watchdog
crw------- 1 root root 247,   0 ... /dev/watchdog0

Kernel-Meldungen kontrollieren:

sudo dmesg | grep -i watchdog

Ausgabe:

[    1.240184] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer

3. Methode A: Nativer systemd-Watchdog (Empfohlen)

Moderne Linux-Systeme mit systemd bringen eine native, ressourcenschonende Watchdog-Anbindung mit, ohne dass zusätzliche Hintergrundprogramme installiert werden müssen.

systemd PID 1 Watchdog konfigurieren

Datei /etc/systemd/system.conf bearbeiten:

sudo nano /etc/systemd/system.conf

Folgende Zeilen einkommentieren und konfigurieren:

[Manager]
# Hardware-Watchdog Timeout (Broadcom Maximum: 15 Sekunden)
RuntimeWatchdogSec=15s

# Watchdog Timeout waehrend des Herunterfahrens/Neustarts
RebootWatchdogSec=5min

# KExec Timeout
KExecWatchdogSec=0

Funktionsweise von systemd

Mit RuntimeWatchdogSec=15s öffnet systemd PID 1 die Gerätedatei /dev/watchdog und sendet automatisch im halben Intervall (alle 7,5 Sekunden) einen Heartbeat an die Hardware.
Friert systemd PID 1 oder der Kernel ein, läuft der Timer nach spätestens 15 Sekunden ab und die Hardware startet das Board neu.
RebootWatchdogSec=5min: Schützt vor hängenden Unmount-Vorgängen beim regulären Neustart. Sollte ein blockiertes Netzlaufwerk das Herunterfahren blockieren, erzwingt der Hardware-Timer nach 5 Minuten den Neustart.

Konfiguration ohne Neustart neu laden:

sudo systemctl daemon-reload

Prüfen, ob systemd den Hardware-Watchdog übernommen hat:

sudo journalctl -u systemd -b | grep -i watchdog
# Ausgabe: Using hardware watchdog 'Broadcom BCM2835 watchdog timer', timeout 15s...

4. Methode B: Der erweiterte Linux-Watchdog-Daemon

Benötigt deine Installation weitergehende Systemprüfungen – z. B. automatischer Neustart bei Überhitzung der CPU über 80 °C, Verlust des Netzwerk-Gateways oder Ausfall eines Anwendungsdienstes –, empfiehlt sich das eigenständige Paket watchdog.

Ausschließliche Nutzung

Betreibe niemals gleichzeitig systemd RuntimeWatchdogSec und den Dienst watchdog auf /dev/watchdog. Wird der eigenständige Daemon genutzt, muss RuntimeWatchdogSec in /etc/systemd/system.conf auskommentiert werden.

Installation & Konfiguration

Paket installieren:

sudo apt update
sudo apt install -y watchdog

Konfigurationsdatei /etc/watchdog.conf öffnen:

sudo nano /etc/watchdog.conf

Regeln für den industriellen Einsatz eintragen:

# Watchdog-Geraetedatei
watchdog-device = /dev/watchdog

# Hardware-Timeout (15 Sekunden) und Pruefintervall (alle 4 Sekunden)
watchdog-timeout = 15
interval = 4

# Regel 1: Neustart bei CPU-Last ueber 24.0 (Schutz vor Fork-Bombs)
max-load-1 = 24

# Regel 2: Neustart bei freiem Arbeitsspeicher unter 32 MB (OOM-Schutz)
min-memory = 32768

# Regel 3: Neustart bei CPU-Temperatur ueber 80 °C (Schutz vor Hitzetod)
max-temperature = 80
temperature-sensor = /sys/class/thermal/thermal_zone0/temp

# Regel 4: Netzwerk-Pruefung (Ping an Standard-Gateway)
ping = 192.168.1.1
interface = eth0

# Echtzeit-Prioritaet fuer den Daemon aktivieren
realtime = yes
priority = 1

Dienst aktivieren und starten:

sudo systemctl enable --now watchdog

Status prüfen:

sudo systemctl status watchdog

5. Fehlersimulation & Funktionstest

Gehe niemals mit einem Watchdog live, ohne vorher in einem kontrollierten Test nachgewiesen zu haben, dass der Hardware-Reset unter Last zuverlässig auslöst.

Test 1: Simulierter Kernel-Absturz (Panic)

Der Linux-Kernel bietet über das SysRq-Interface die Möglichkeit, einen sofortigen Kernel-Absturz zu provozieren:

# Erzeugt eine sofortige Kernel Panic
echo c | sudo tee /proc/sysrq-trigger

Verhalten beobachten: 1. Die SSH-Sitzung friert auf der Stelle ein. 2. Da der Kernel abgestürzt ist, kann kein Heartbeat mehr an den Hardware-Timer gesendet werden. 3. Nach exakt 15 Sekunden blinken die LEDs des Raspberry Pi kurz auf und das System führt einen echten Hardware-Kaltstart durch. 4. Nach etwa 40 Sekunden ist das System wieder vollständig via SSH erreichbar.

Test 2: Fork-Bomb Stresstest

Wurde max-load-1 = 24 im Daemon konfiguriert, lässt sich die Prozesserschöpfung testen:

# ACHTUNG: Startet eine exponentielle Prozess-Schleife in einer Subshell
:(){ :|:& };:

Ergebnis: Binnen Sekunden schnellt die CPU-Last nach oben. Der Watchdog-Daemon erkennt das Überschreiten des Grenzwerts, stellt das Senden von Lebenszeichen an /dev/watchdog bewusst ein und lässt den Silizium-WDT die Maschine zuverlässig neu starten.

6. Häufige Fehler & Best Practices

Das "Magic Close"-Zeichen

Die Linux-Watchdog-Schnittstelle verfügt über eine Schutzlogik gegen versehentliche Neustarts, wenn ein Administrator den Dienst stoppt: - Schreibt ein Prozess vor dem Schließen der Gerätedatei den ASCII-Buchstaben 'V' (Magic Close) nach /dev/watchdog, deaktiviert der Kernel den Timer. - Stürzt der Prozess hingegen ab oder wird er unsauber beendet (kill -9), bleibt der Timer scharf und führt nach Ablauf der 15 Sekunden unweigerlich zum Hardware-Reset.

Dauerhafte Boot-Schleifen verhindern

Um zu verhindern, dass ein defekter Sensor oder ein fehlerhaftes Startskript das System in einer permanenten Neustartschleife festhält, empfiehlt sich ein Startzähler auf der persistenten /data-Partition:

#!/usr/bin/env bash
# /usr/local/bin/boot_audit.sh
BOOT_COUNT_FILE="/data/boot_count.txt"

COUNT=$(cat "$BOOT_COUNT_FILE" 2>/dev/null || echo 0)
COUNT=$((COUNT + 1))
echo "$COUNT" > "$BOOT_COUNT_FILE"

# Nach 10 Minuten stabilem Betrieb den Zaehler zuruecksetzen
sleep 600 && echo 0 > "$BOOT_COUNT_FILE" &

Nächste Schritte

Mit unzerstörbarem Dateisystem und autonomer Hardware-Selbstheilung geht es an die Container-Orchestrierung:

Edge-Containerisierung & K3s-Clustering: Betreibe hochverfügbare Container-Workloads auf gehärteten Edge-Nodes.
Festplattenloser Netzwerk-Boot (PXE): Betreibe Raspberry Pi Flotten komplett ohne lokale SD-Karten oder SSDs über das Netzwerk.