RPI - Log-Flut und die Folgen ...
... SD-Karte kaputt geschrieben - Crash - und was dagegen tun?
Ein Jeder, der seinen Home-Server mittels Raspberry Pi in Betrieb hat und dieser dann (hoffentlich) seit einiger Zeit störungsfrei in Betrieb ist, wird irgendwann vom Schicksal eingeholt:
CRASH !!
Man/frau wird den Pi noch einmal starten und glücklich sein, dass er wieder hochläuft. Aber ein ungutes Gefühl bleibt zurück. Warum ist er abgestürzt? Kann dies wieder passieren? Was, wenn die Daten verloren gehen? Liegt es wirklich daran, dass die SD-Karten kaputt-geschrieben werden?
Ursachenforschung:
Wir schauen uns zunächst einmal ein paar Daten an, dann entscheiden wir: Bedauerlicherweise gibt es kein allgemein gültiges Tool, mit dem man die Lebensparameter einer SD-Karte auslesen könnte, ähnlich dem SMART-System einer SSD.
Mit dem Tool dumpe2fs können wir uns aber vom Root-Dateisystem ein paar Informationen einholen:
# dumpe2fs /dev/mmcblk0p2 | grep Lifetime
dumpe2fs 1.44.5 (15-Dec-2018)
Lifetime writes: 35 GB
OK !!! Das ist eine Aussage! Innerhalb des "Lebenszyklus" dieses Dateisystem wurden bereits 35 GB geschrieben. Das ist viel, zu viel? Und, wie alt ist dieses Dateisystem eigentlich?
# dumpe2fs /dev/mmcblk0p2 | grep created
dumpe2fs 1.44.5 (15-Dec-2018)
Filesystem created: Wed Dec 2 13:55:23 2020
# dumpe2fs /dev/mmcblk0p2 | grep "Last mount"
dumpe2fs 1.44.5 (15-Dec-2018)
Last mounted on: /
Last mount time: Wed Aug 4 17:17:01 2021Entscheidend sind hier also die Differenz zwischen der "created"-Zeit und "Last mounted"-Zeitpunkt. Dies sind hier gerade einmal acht Monate. Definitiv zu viele GB pro Monat !!!
Frage also: Wer schreibt und warum so viel? Nun, hier hilft uns ein Programm iotop:
# iotop -aok
Dies lassen wir dann mal für einige Minuten laufen und kontrollieren:
Total DISK READ: 0.00 K/s | Total DISK WRITE: 0.00 K/s
Current DISK READ: 0.00 K/s | Current DISK WRITE: 0.00 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1674 be/4 root 0.00 K 28.00 K 0.00 % 0.21 % portainer
83 be/3 root 0.00 K 172.00 K 0.00 % 0.13 % [jbd2/mmcblk0p2-]
591 be/4 root 0.00 K 4.00 K 0.00 % 0.00 % nmbd --fo~cess-g
643 be/4 root 0.00 K 16.00 K 0.00 % 0.00 % svlogd -t~/log/
887 be/4 root 0.00 K 24.00 K 0.00 % 0.00 % gammu-sms~d --dae
13062 be/4 roo 0.00 K 44.00 K 0.00 % 0.00 % rsyslogd ~ain Q
Hier wird also reichlich geschrieben. Nun, das Logging ist eine gute Lösung zur Fehlersuche, aber wenn das System erst mal läuft, wer kontrolliert dann permant die Logs? Ich nicht, dienstlich ja, meistens, aber privat? Also möchte ich, dass so wenig wie möglich geloggt wird. Die große Keule schwingen wir in der Datei:
# vi /etc/rsyslog.conf
###############
#### RULES ####
###############
*.* ~ # keine LOGS MEHR SCHREIBEN
Also direkt unter der Rubrik RULES setzen wir den Filter, der dann alles erst einmal killt. Dann noch den rsyslogd neustarten und es herscht erstmal Ruhe.
# service rsyslog stop
# service rsyslog start
Sollte man das Logging zur Fehlersuche wieder benötigen, kann man die Schritte leicht wieder rückgängig machen.
Und so sollte die SD-Karte DEUTLICH länger halten, bis zum nächsten Crash.