Jasper Grahl

Raspberry Pi im Dauerbetrieb: Was ein kurzer Stromausfall über mein System verraten hat

· 5 Min. Lesezeit · Auch auf English

Mein Energiemanagement JG Energy läuft rund um die Uhr auf einem Raspberry Pi 5 mit SSD. Es steuert Wallbox, Hausakku und Ladepläne für zwei E-Autos. Fällt der Pi aus, merkt man das im Alltag – spätestens, wenn das Auto morgens nicht geladen ist.

Anfang November gab es morgens einen kurzen Stromausfall. Der Pi startete danach von selbst wieder, und alles lief weiter. Trotzdem hat dieser Vorfall vier Schwachstellen gezeigt, die ich vorher nicht kannte.

Schritt 1: War es wirklich ein Stromausfall?

Mein erster Verdacht war ein Absturz. Um das zu klären, hilft ein einfacher Trick: die Laufzeit aller Geräte vergleichen. Starten Pi, Shellys und andere Geräte zur selben Minute neu, war es der Strom. Steht nur der Pi bei null, war es der Pi.

Shellys ab Generation 2 liefern ihre Laufzeit über die lokale API:

curl -s http://<shelly-ip>/rpc/Shelly.GetStatus | jq .sys.uptime
# → Sekunden seit dem letzten Start

Für den Pi selbst reicht uptime -s. Bei mir passten alle Startzeiten auf wenige Sekunden zusammen: Stromausfall.

Schritt 2: Warum gab es keine Logs?

Als Nächstes wollte ich im Systemlog nachsehen, was vor dem Neustart passiert war. Ergebnis: nichts. Das Log begann mit dem Neustart.

Dabei hatte ich das dauerhafte Journal schon früher eingeschaltet – mit Storage=persistent in /etc/systemd/journald.conf. Das Problem: Raspberry Pi OS überschreibt diese Einstellung. Es bringt eine eigene Zusatzdatei mit:

/usr/lib/systemd/journald.conf.d/40-rpi-volatile-storage.conf
→ Storage=volatile

Dateien in journald.conf.d/ haben Vorrang vor der Hauptdatei. Meine Einstellung war also wirkungslos, und das Log lag nur im Arbeitsspeicher. Bei jedem Neustart war es weg – auch das, von dem man nach einem Absturz am dringendsten wissen will, was davor passiert ist.

Welche Einstellung wirklich gilt, zeigt:

systemd-analyze cat-config systemd/journald.conf

Die Lösung ist eine eigene Zusatzdatei mit höherer Nummer, die als letzte gelesen wird:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/99-dauerhaft.conf <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=500M
EOF
sudo systemctl restart systemd-journald
sudo journalctl --flush

Ob es geklappt hat, zeigt journalctl --list-boots: Nach dem nächsten Neustart sollten dort mehrere Einträge stehen. Das Log des vorherigen Starts liefert dann journalctl -b -1.

Auf einer SSD ist das unproblematisch. Auf einer SD-Karte sollte man wegen der Schreiblast etwas genauer abwägen.

Schritt 3: Die verlorene Startmeldung

JG Energy schickt nach jedem Start eine Telegram-Nachricht. Nach dem Stromausfall kam keine. Im Log stand:

⚠️ Telegram Fehler: getaddrinfo EAI_AGAIN api.telegram.org

EAI_AGAIN heißt: Die Namensauflösung ist vorübergehend nicht möglich. Der Pi startet nach einem Stromausfall schneller als Router und Internetanschluss. Als JG Energy die Nachricht senden wollte, gab es schlicht noch kein Internet. Die Nachricht war verloren.

Mit After=network-online.target im systemd-Dienst lässt sich das nicht lösen: Der Pi hat dann zwar eine Netzwerkverbindung, der Router aber noch keine Verbindung nach draußen.

Die Lösung ist eine Warteschlange. Scheitert eine Nachricht an einem Netzwerkfehler, wird sie zurückgestellt und jede Minute erneut versucht:

function wiederholbar(err) {
  const status = err?.response?.status;
  return !status || status === 429 || status >= 500;   // kein Status = keine Antwort
}

Schritt 4: Sauber beendet oder abgestürzt?

Die Startmeldung beantwortet jetzt auch gleich die Frage, die ich mir nach dem Stromausfall gestellt habe:

🟢 JG Energy gestartet
⚠️ Auch der Pi ist neu gestartet (vor 1 min)
⚠️ Letzter Lauf wurde NICHT sauber beendet (zuletzt gesehen 09:22)

Dafür braucht es nur zwei Dinge:

Schritt 5: Hardware-Watchdog gegen Hänger

Ein Stromausfall ist harmlos, weil der Pi danach von selbst startet. Gefährlicher ist ein Pi, der hängt: Er ist eingeschaltet, reagiert aber nicht mehr. Dann startet nichts neu.

Dagegen hilft der Hardware-Watchdog, den der Raspberry Pi eingebaut hat. systemd muss ihn regelmäßig „füttern“. Bleibt das aus, startet die Hardware den Pi neu. Der Watchdog des Pi erlaubt höchstens etwa 15 Sekunden, deshalb nehme ich 14:

sudo mkdir -p /etc/systemd/system.conf.d
sudo tee /etc/systemd/system.conf.d/watchdog.conf <<'EOF'
[Manager]
RuntimeWatchdogSec=14s
EOF
sudo systemctl daemon-reexec

Prüfen lässt sich das mit:

systemctl show -p RuntimeWatchdogUSec     # → 14s
dmesg | grep -i watchdog

Der Watchdog überwacht das System, nicht das Programm. Stürzt nur JG Energy ab, übernimmt das der systemd-Dienst mit Restart=always.

Schritt 6: Die Geräte müssen ohne Server sicher sein

Die wichtigste Frage beim Dauerbetrieb ist nicht, wie schnell der Server wieder läuft. Sondern: Was machen die Geräte, solange er weg ist?

Bei der Wallbox habe ich das so gelöst, dass jede Sperre, die der Server setzt, nach höchstens zwei Stunden von selbst abläuft. Fällt der Pi aus, lädt die Wallbox danach wie eine ganz normale Wallbox. Das Auto ist morgens voll – wenn auch nicht mit Sonnenstrom.

Beim Hausakku gibt es diese Möglichkeit nicht. Fällt der Server aus, während die Entladung beim Überschussladen gesperrt ist (Einstellung „Bleibt aus“), bleibt sie gesperrt. Ich habe abgeschätzt, wie oft genau diese Kombination auftritt, und nehme sie bewusst in Kauf. Wichtig ist, dass man die Lücke kennt.

Fazit

Ein kurzer Stromausfall hat bei mir keinen Schaden angerichtet. Aber er hat gezeigt, dass ich ohne Logs und ohne Startmeldung im Ernstfall nicht gewusst hätte, was passiert ist.

Meine Liste für jeden Pi, der etwas Wichtiges steuert: