Drei Prüfungen, die jede Doichain-Node braucht
Eine Node auf der falschen Kette oder ohne neue Blöcke liefert falsche Daten, ohne auszufallen. Drei einfache Prüfungen und ein korrigierter Docker-Pfad schützen davor.
Die meisten Störungen einer Node sind leicht zu erkennen: Der Prozess läuft nicht, die Platte ist voll. Gefährlicher sind Fehler, bei denen alles normal aussieht. Eine Node, die der Altkette folgt oder seit Stunden keinen Block gesehen hat, beantwortet weiter jede Anfrage, nur eben falsch. Drei Prüfungen gehören deshalb in jede Überwachung.
1. Folgt die Node der richtigen Kette?
Seit dem Upgrade vom 11. September 2026 gibt es zwei Ketten. Die Doichain erkennt man an Block 431018:
doichain-cli getblockhash 431018
# erwartet: 71d50ff12b090561cc918ddb560334b4350758c7eace3f058dd332fb112f4b67
Liefert die Node bab49c13…2d34, steht sie auf der Altkette. Dann hilft nur: Node stoppen, auf Doichain Core 31 aktualisieren, ein vorhandenes Wallet sichern, das Datenverzeichnis löschen und neu synchronisieren. Das dauert nur Minuten. Die Prüfung gehört ins Monitoring, mit Alarm, falls sich das Ergebnis je ändert. Ohne eigene Node meldet die Doichain-API das Ergebnis unter fork_check.
2. Kommen neue Blöcke?
Ein Alarm nach 15 Minuten ohne Block wäre auf der Doichain ein Fehlalarm. Blöcke entstehen zufällig, und die Hashleistung kommt von wenigen Merged-Mining-Pools. Pausen von 30 bis 60 Minuten kommen vor. Bewährt hat sich ein Alarm nach 90 Minuten ohne neuen Block. Kommt netzwerkweit kein Block, zeigt der Vergleich mit dem Referenz-Explorer, ob die eigene Node betroffen ist oder alle.
3. Stimmt die Höhe?
Die Blockhöhe der eigenen Node sollte nur wenige Blöcke vom Referenz-Explorer abweichen. Der liefert sie maschinenlesbar unter https://doi-explorer.le-space.de/api/getblockcount. Eine deutlich höhere Zahl ist kein gutes Zeichen, sondern ein typisches Merkmal der Altkette, die weit vorausgeeilt ist.
Ein Check für alle drei
#!/bin/bash
EXP=71d50ff12b090561cc918ddb560334b4350758c7eace3f058dd332fb112f4b67
H=$(doichain-cli getblockhash 431018) || { echo "RPC nicht erreichbar"; exit 3; }
[ "$H" = "$EXP" ] || { echo "FALSCHE KETTE"; exit 2; }
T=$(doichain-cli getblock "$(doichain-cli getbestblockhash)" | grep '"time"' | head -1 | tr -dc 0-9)
ALTER=$(( $(date +%s) - T ))
[ $ALTER -lt 5400 ] || { echo "seit $ALTER s kein Block"; exit 1; }
echo "ok, letzter Block vor $ALTER s"
Das Skript lässt sich in Uptime Kuma, Checkmk oder jedes andere Monitoring einbinden. Exit-Code 0 heißt gut, die übrigen Codes unterscheiden „RPC nicht erreichbar“, „falsche Kette“ und „kein Block“. Den Höhenvergleich mit dem Explorer ergänzt man im selben Werkzeug als HTTP-Prüfung.
Korrektur: der Docker-Pfad
In unserer Anleitung Node betreiben stand ein falscher Pfad für das Datenvolume. Das Image doichain/core läuft als Benutzer doichain und hält seine Daten unter /home/doichain/data/doichain. Richtig ist deshalb:
docker run -d --name doichain \
-e RPC_PASSWORD='ein-starkes-passwort' \
-v /srv/doichain:/home/doichain/data/doichain \
-p 8338:8338 doichain/core:v31.1.6
Wer den alten Pfad /root/.doichain eingebunden hat, dessen Kettendaten liegen nur im Container und sind beim Löschen des Containers weg. Die Kette lässt sich in Minuten neu synchronisieren. Wichtig ist das aber für ein Wallet im Container: Es vor jeder Änderung mit backupwallet sichern. Das Verzeichnis auf dem Host muss dem Container-Benutzer gehören, dessen Benutzer-ID zeigt docker run --rm --entrypoint id doichain/core:v31.1.6.
Mehr lernen
Installation, Indizes, Härtung, Überwachung und Störungsbehebung behandelt der kostenlose Kurs Node Operator Associate der Doichain Academy.