Raspi 3 hängt sich alle zwei bis drei Wochen auf

Dr. Boris Neubert · 27 August 2017, 13:05:15

Hallo,

mein FHEM läuft auf einem Raspberry Pi 3 unter Raspbian (Debian 8.0). Alle zwei bis drei Wochen hängt sich die Maschine auf.

Folgende Symptome:
- Es wird nichts mehr auf die Platte geschrieben.
- Syslog loggt nicht mehr (ich habe auf rsyslog umgestellt und auf dem Remotehost kommt ab dem Zeitpunkt des Crashs nichts mehr an).
- Kein ssh mehr auf den Rechner möglich (Connection closed).
- FHEM läuft rudimentär weiter. Es wird nichts mehr geloggt und nicht mehr automatisch geschaltet. Es wird aber z.B. noch immer ein neues Bild über RSS an den Browser ausgeliefert. Die darauf angezeigte Uhrzeit geht 2 Stunden nach.

Als Abhilfe habe ich folgendes fest installiert:
- Ich habe ein ausreichend dimensioniertes Netzteil.
- Ich boote von SD-Card und habe / auf einer externen USB-Platte.
Das Problem trat auch vorher schon auf (mit / auf SD-Card).

Ich vermute, dass das Problem mit einem entzogenen Dateisystem zusammen hängt. / ist ext4, /var, /tmp, /opt/fhem, /opt/scratch sind ext4 auf LVM.

Ich suche Anregungen, wie ich dem Problem auf die Schliche kommen kann.

Viele Grüße
Boris

CoolTux · 27 August 2017, 13:23:06

Und wie sehen die letzten 50 Logzeilen aus?

Dr. Boris Neubert · 27 August 2017, 14:18:06

Danke für Deine Antwort.

Ich kann kein Problem im Log erkennen - vielleicht siehst Du etwas im anhängenden Log.

CoolTux · 27 August 2017, 14:25:45

Da steht nichts. Eventuell in der messages zum Zeitpunkt eines Ausfalles. Und dmsg oder so ähnlich wäre noch hilfreich.

Dr. Boris Neubert · 27 August 2017, 14:55:26

Hallo,

das sind die Messages zum Zeitpunkt des Ausfalls. Ich sende alle Nachrichten per rsyslog an den fremden Rechner. Hintergrund ist, dass ich im lokalen Syslog auch schon nichts gesehen hatte und vermutete, dass die interessanten Zeilen nicht mehr geschrieben werden konnten, so dass ich sie nach dem Reboot nicht mehr sehe, und habe daher rsyslog aktiviert. Aber es werden auch keine interessanten Zeilen an den fremden Rechner übertragen.

Ich habe nach dem Crash keine Möglichkeit mehr, auf den Raspi zu kommen, um dmesg auszuführen oder zu analysieren, woran es hängt. Ich muss den Reset-Knopf drücken.

Bitte frage weiter! Vielleicht übersehe ich einen Kniff, doch noch mehr Informationen zu sammeln.

Viele Grüße
Boris

CoolTux · 27 August 2017, 15:03:37

Wie gesagt es gibt noch die /var/log/messages eventuell steht da was. Ansonsten wäre so ein Verhalten Richtung Speicher oder Storage zu suchen.
Pro forma Mal die SD Karte tauschen.
Was genau hat es mit dem LVM auf sich? Aber da würde ja wenn gleich nach dem boot was kommen und nicht erst nach Tagen.
Vielleicht läuft auch was voll.

KölnSolar · 27 August 2017, 15:15:25

Klingt ähnlich wie hier, wobei Sonderfall USB-Stick anstatt SD-Card.
Hab nach wie vor keine Lösung u. erkläre es mir nach wie vor mit "USB-Problemen".
Good luck
Markus

viegener · 27 August 2017, 15:56:46

Freies Spekulieren ist ja wohl erlaubt hier....

Für mich wäre der Ansatzpunkt, dass eigentlich nichts mehr geht (inklusive syslog), aber trotzdem per RSS noch etwas geliefert wird und FHEM rudimentär weiterläuft. Das passt mit dem restlichen Verhalten nicht zusammen.

Wenn es die Filesysteme sind, wäre ja vielleicht ein dumpen alle 5 Sekunden der Ausgabe von df (oder ähnliches) in ein Verzeichnis auf der SD hilfreich?
Alternativ auch mal Ausgaben von top?
Passiert das auch ohne laufendes FHEM?

Wie gesagt alles Spekulation...

Wernieman · 27 August 2017, 16:50:21

Also scheinbar laufen alle Programme im Speicher weiter, das hört sich nach io-Problemen an, also SDCard bzw. bei Dir USB-Stick / USB-Probleme.

Bei einem Rechner würde ich auch die Festplattencontroller prüfen, nur beim Pi .....

Kannst Du ins Netzwerk loggen? z.b. haben viele NAS die Möglichkeiten, einen Logserver aufzusetzen, oder einen 2. Rechner ...

Weiß jetzt aktuell nicht beim Pi, wie ist eigentlich die SDCard angeschlossen?

Dr. Boris Neubert · 27 August 2017, 17:15:11

Hallo,

wie gesagt, ich logge per rsyslog alles, was in irgendwelche Logs ins /var/log verstreuselt wird, in eine Log-Datei auf einem Remote Host. Das ist soweit also vollständig.

Das Problem trat früher auf, als ich nur eine SD-Karte hatte für Boot und Root und auch jetzt, wo Root und weitere Verzeichnisse auf einer externen USB-Platte (nicht Stick) liegen (SD-Karte wird daher nach dem Booten nicht mehr angesprochen). Auf allen Verzeichnissen (außer /boot) sind noch mehrere bis mehrere hundert GB frei. Es liegt m.E. daher weder an SD-Karte noch an Platte.

Ob es ohne laufendes FHEM auch geschieht, weiß ich nicht, weil ich das nur testen kann, indem ich meine Hausautomation solange auf einen zweiten Rechner verschiebe.

Ich befürchte, dass ich einen eigenen Prozess schreiben muss, der Daten sammelt und periodisch auf einen anderen Rechner schubst, und hoffen, dass das Schubsen nach dem Crash noch funktioniert (so wie der Zugriff auf den in FHEM eingebauten Webserver, der mir nach dem Crash per RSS noch die Uhrzeit und Bilder ausliefert, aber ansonsten nicht mehr reagiert).

Ich tippe im Moment entweder auf eine Störung im Zugriff auf das Filesystem (die per RSS ausgelieferten Bilder könnten im Cache liegen) oder eine Störung im TCP/IP-Stack (und nur die bestehende TCP-Verbindung für RSS bleibt am Leben).

Viele Grüße
Boris

Wernieman · 28 August 2017, 08:02:35

Ich habe nicht gesagt, das es am frreien Platz liegt, sondern am IO-System. Deine Folgende Aussage zieht eigentlich auf das gleiche:

Zitat... Zugriff auf das Filesystem ...

Wie schon gefragt: Kannst Du das Filesystem prüfen?

Dr. Boris Neubert · 28 August 2017, 12:15:50

Zitat von: Wernieman am 28 August 2017, 08:02:35
Wie schon gefragt: Kannst Du das Filesystem prüfen?

Ich kann heute abend nochmal explizit fsck laufen lassen und sehen, was gemeldet wird. fsck prüft und reparierte nach dem letzten Reset beim Booten automatisch, weil durch das Filesystem ja wegen des harten Abbruchs durch den Reset unclean war.

Nach einem Crash und vor einem Reboot sind meine Möglichkeiten begrenzt, weil ich nicht mehr auf den Raspi komme. Ich könnte alle 5 Minuten prüfen, ob man noch schreiben kann, und im Fehlerfall fsck auslösen und das Protokoll verschicken. Ich zweifele aber daran, dass das noch funktioniert, weil vermutlich nicht einmal mehr vom Filesystem gelesen werden kann, um fsck auszuführen.

Gibt es noch Vorschläge für weitere Werkzeuge zur Prüfung des Filesystems?

Grüße
Boris

Wernieman · 28 August 2017, 12:35:04

Du sagtest, das die Logfiles auf einen anderen Server geschickt werden ... hast Du das Kernlog? bzw. kannst Du dort nach "i/o" greppen?

mahowi · 28 August 2017, 12:37:01

Werden eventuell viele kleine Dateien z.B. nach /tmp oder /var/tmp geschrieben, die bis zum Reboot nicht mehr gelöscht werden? Eventuell gehen Dir dann die Inodes aus, obwohl noch massig Platz da ist. Was sagt denn df -i?

connormcl · 28 August 2017, 13:30:54

Zitat von: mahowi am 28 August 2017, 12:37:01
Werden eventuell viele kleine Dateien z.B. nach /tmp oder /var/tmp geschrieben, die bis zum Reboot nicht mehr gelöscht werden? Eventuell gehen Dir dann die Inodes aus, obwohl noch massig Platz da ist. Was sagt denn df -i?

Das ist auf jeden Fall ein interessanter Aspekt. Schreibt FHEM solche vielen kleinen Dateien oder was macht das am ehesten?

Wie ich bisher gelesen habe, kann man die Inodes-Anzahl nur beim Formatieren einer Partition ändern. Das führt zu einigem Ärger in Bezug auf den Raspberry Pi, da hier gewöhnlich keine Partitionen formatiert werden, sondern diese direkt aus einem Image kommen, welches auf die SD-Karte geklont wird.

Jetzt ist die Frage, wie /tmp und /var/tmp eingehängt sind und wo sie physikalisch liegen...und welche Werte dafür gelten.

Am einfachsten könnte man wohl einen Aufräumprozess implementieren, um alte Dateien zu löschen...