Raspberry Pi: Crash statt Dauer-Hänger (I/O Watchdog einrichten)

Wenn bei einem Raspberry Pi I/O-Vorgänge hängen bleiben (beispielsweise bei alten SD-Karten oder bei USB-SATA-Adaptern) , wechselt der betroffene Prozess in den ununterbrechbaren Tiefschlaf (D-State). Das System friert oft lautlos ein, reagiert auf nichts mehr, bootet aber auch nicht neu.

Da kann es empfehlenswert sein,
1. in solchen Fällen eine Kernel panic auszulösen, sowie
2. dafür Sorge zu tragen, dass jedwede Panic am Ende zu einem Reboot führt

Und das geht so:

Das Zusammenspiel der Timer

Um das Verhalten perfekt auf die Bedürfnisse abzustimmen, muss man zwei Timer-Phasen verstehen und definieren:

1. Phase 1: Der hung_task_timeout_secs-Timer Dies ist die Geduldsphase des Kernels. Wenn ein Prozess im ununterbrechbaren D-State festsitzt, schaut sich der Kernel das stoisch an. Erst wenn die hier definierte Zeit (in Sekunden) am Stück abgelaufen ist, verliert der Kernel die Geduld und triggert (falls hung_task_panic=1 aktiv ist) sofort die Kernel-Panic.
   • Abwägung: Zu kurz (z.B. < 60s) kann bei legitimer hoher Last (z.B. Backup-Peaks) zu Fehlalarmen führen. Zu lang (z.B. > 1200s) lässt das System unnötig über 20 Minuten tot im Rack oder wo auch immer hängen.
2. Phase 2: Der kernel.panic-Timer
   Gilt für jede Panic!
   Sobald die oben veranlasste oder irgendeine andere Panic ausgelöst wurde, friert der Kernel das System im Textmodus ein, auf der Konsole steht dann ein panic-dump. Der kernel.panic Timer bestimmt, wie viele Sekunden der Kernel nun verweilt, bevor er das harte Reset-Signal an die Hardware sendet.
   • Abwägung: Stellt man hier 0 ein, bleibt der Pi ewig im Panic-Screen stehen (Werkseinstellung bei manchen Systemen). Der Administrator hätte alle Zeit der Welt, um auf der Konsole zu überprüfen, wo es “hängt”¹. Stellt man einen Wert wie 180 (3 Minuten) ein, hat ein Admin vor Ort oder an der seriellen Konsole genug Zeit, den Stack-Trace zu lesen oder abzufotografieren. Danach erfolgt der erlösende Reboot.

Gesamtzeit bis zum Reset-Signal = Hung-Timeout + Panic-Verzögerung

Einrichtung in 3 Schritten

1. Konfigurationsdatei anlegen

Erstellen einer dedizierten Konfigurationsdatei im Sysctl-Verzeichnis (durch die hohe Nummer 99 überschreibt sie alle Standardwerte beim Booten verlässlich):

sudo nano /etc/sysctl.d/99-hung-cure.conf

2. Parameter eintragen

Die folgenden drei Zeilen (nach Wunsch inkl. Kommentare) einfügen. Sekunden-Werte an die eigenen Anforderungen anpassen (hier beispielhaft: 7 Minuten Geduld, danach 3 Minuten Zeit zum Konsole gucken):

# Nach 7 Minuten (420s) I/O-Blockade eine Kernel-Panic auslösen
kernel.hung_task_timeout_secs = 420
kernel.hung_task_panic = 1

# Exakt 3 Minuten (180s) nach der Panic hart neu starten
kernel.panic = 180

3. Scharfschalten im laufenden Betrieb

Ein Reboot würde diese Konfiguration aktivieren.

Den kann man sich ersparen und die Einstellungen sofort aktivieren, wobei man auch gleich noch die Wirksamkeit der Einstellungen verfizieren kann:

sudo sysctl --system | grep -E 'panic|hung'

Erwartete Ausgabe bei Erfolg:

* /etc/sysctl.d/99-hung-cure.conf wird angewendet …
kernel.hung_task_timeout_secs = 420
kernel.hung_task_panic = 1
kernel.panic = 180

Ab jetzt ist das System im Ernstfall geschützt: Wenn die Hardware blockiert, crasht der Pi kontrolliert, lässt einem ein Zeitfenster zur Analyse und holt sich danach via Auto-Reboot selbst wieder ans Netz.