Der Dienst heißt hdd-standby-watchdog. Seine Aufgabe: prüfen, ob der ZFS-Pool ruht, und die Platten dann per hdparm -y schlafen legen. Seit dem 7. Juli 2026 um 20:06 stand er in activating (start). Also 78 Tage lang. Ein Wächter, der 78 Tage auf eine Antwort wartet, ist kein Wächter — das ist ein Jedi, der im Rat sitzt und nichts tut.
Von außen sah es nach einem Festplattenproblem aus: Eine Platte in srv-mandalore blieb dauerhaft active/idle, die anderen drei schliefen. Der Verdacht lag nahe, dass wieder die Firmware der WD-Red-Laufwerke dazwischenfunkt. Tat sie aber nicht. Die Platte war die ganze Zeit das Opfer, nicht der Täter.
Das Problem
Der Host hat vier Platten im RAID-Z2. Eine davon ließ sich nicht in den Standby bringen, obwohl der Pool ruhte. Für die Überwachung gab es ein Zabbix-Item mit einer 90-Minuten-Schwelle, also 5400 Sekunden. Der Live-Wert stand beim Prüfen bei 1499 Sekunden. Die Anzeige war unauffällig, der Dienst war es nicht.
Der entscheidende Hinweis kam nicht von den Platten, sondern von systemd:
systemctl status hdd-standby-watchdog.service
journalctl -u hdd-standby-watchdog.service -n 20 --no-pager
Status activating (start) seit dem 7. Juli. Kein Fehler, kein Exit-Code, kein Neustartversuch. Ein oneshot-Dienst, der nie fertig wird, bleibt einfach stehen. Der stündliche Timer startet währenddessen keine zweite Instanz — systemd sieht den Dienst ja noch als laufend an.
Die Diagnose
Der Prozessbaum brachte die Erklärung:
systemctl status hdd-standby-watchdog.service
ps -o pid,ppid,etime,time,stat,wchan:32,cmd -p <MAIN-PID>
Die Main-PID stand in pipe_read. Der Kindprozess war 78 Tage alt und hatte in dieser Zeit 3 Stunden 43 Minuten CPU verbraucht. pipe_read heißt: Der Prozess wartet auf das Ende eines anderen Prozesses und liest dessen Ausgabe. In diesem Fall wartete er auf hdparm -C.
hdparm -C fragt den Laufwerkszustand ab. Auf einer Platte, die gerade nicht antwortet, kann dieser Aufruf beliebig lange hängen. Ohne Timeout gibt es keine zweite Gelegenheit: Das Skript kommt nie zur Zeile mit hdparm -y, weil es schon beim Zustands-Check feststeckt. Der Watchdog hat also nicht die Platte überwacht, sondern auf sie gewartet. Und zwar sehr geduldig.
Das erklärt auch das Muster: Die drei Platten, die auf den Check antworteten, waren längst im Standby — vermutlich von einem früheren Lauf. Die vierte antwortete nicht, blockierte den Check, und blieb deshalb active/idle. Kein Ausfall, sondern eine Blockade.
Die Ursache
Es war kein Konfigurationsfehler. Die Platte stand korrekt in DRIVES. Der Dienst hat sie also von Anfang an bearbeitet — nur eben nie zu Ende.
Die Ursache ist der fehlende Timeout um einen externen Befehl in einem Watchdog. Genau das macht einen Watchdog wertlos: Wenn die Prüfung selbst hängt, gibt es keinen Alarm, keinen Retry und keinen Spindown. Der Dienst sieht in systemd nicht „kaputt" aus, sondern „beschäftigt". Und beschäftigt bleibt er, bis jemand nachsieht.
Das ist kein exotisches hdparm-Problem. Jeder Watchdog, der fremde Kommandos aufruft, kann an einem hängenden Kommando sterben. Der Zustands-Check ist dabei der gefährlichste Kandidat, weil er als harmlos gilt und deshalb oft ohne Grenze läuft.
Die Firmware-Eigenheit der WD40EFRX und die Tatsache, dass hdparm -C manche Platten aufweckt, hatte ich schon im Juni aufgeschrieben. Wer die Vorgeschichte nachlesen will: ZFS + HDD Standby: Special VDEV und hdparm-Fallen. Diesmal war es die andere Richtung — nicht das Aufwecken, sondern das Warten.
Der Fix
Das Skript bekam drei Zeitgrenzen:
timeout 20 zpool iostat
timeout 5 hdparm -C /dev/$d
timeout 10 hdparm -y /dev/$d
Die Werte sind bewusst gestaffelt. zpool iostat darf 20 Sekunden brauchen, der Zustands-Check 5 Sekunden, der Spindown 10 Sekunden. Danach wird der Dienst neu gestartet:
systemctl restart hdd-standby-watchdog.service
Ergebnis: alle vier Platten standby, der Dienst inactive. Der Watchdog läuft wieder stündlich, und ein hängendes hdparm kostet jetzt höchstens ein paar Sekunden statt eines Quartals.
Eine Einschränkung gehört dazu: Das Repo-Skript ist noch die Fassung ohne Timeout. Seit dem 15. August gab es keinen Commit daran. Der Fix wurde live gesetzt, nicht im Repository nachgezogen. Wer den Host neu aufsetzt und das Skript aus dem Repo nimmt, holt sich den alten Zustand zurück. Das ist eine offene Baustelle, keine erledigte.
Was du mitnimmst
Setz um jeden externen Befehl in einem Watchdog ein timeout — auch um den Zustands-Check. Besonders um den Zustands-Check. Der sieht harmlos aus und ist der Grund, warum der Rest nie läuft.
Prüfe bei einem hängenden Dienst nicht nur den Status, sondern den Prozessbaum: pipe_read plus ein alter Kindprozess sagt dir, welcher Aufruf blockiert. Und überwache die Laufzeit von activating, nicht nur den Exit-Code. Ein Dienst, der seit 78 Tagen startet, ist nicht gesund.
Vier WD Red 4 TB im RAID-Z2 sind für so einen Aufbau übrigens keine schlechte Wahl — WD Red Plus 4TB — solange der Watchdog tatsächlich bis zum hdparm -y kommt. Wer eine günstige externe Kopie neben den Pool legt, kommt mit einer Seagate 4 TB externe USB-HDD aus; als NAS-Alternative in derselben Klasse ist die Seagate IronWolf 4 TB NAS-HDD (5400 rpm, CMR) einen Blick wert. Die Platte kann nichts dafür, wenn ihr Wächter im Rat sitzt.