Pi stürzt alle 2-3 Tage ab - Grund für mich nicht erkennbar

[Wernieman]

Zitat aus der Syslog:

Code Auswählen Erweitern


....
Nov 15 17:48:52 raspberrypi watchdog[1064]: file /opt/fhem/log/fhem.heartbeat was not changed in 180 seconds.
Nov 15 17:48:52 raspberrypi watchdog[1064]: /usr/lib/sendmail does not exist or is not executable (errno = 2)
Nov 15 17:48:52 raspberrypi watchdog[1064]: shutting down the system because of error 250
Nov 15 17:49:02 raspberrypi kernel: [62156.928522] watchdog: watchdog0: watchdog did not stop!
Nov 15 17:49:02 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="428" x-info="http://www.rsyslog.com"] exiting on signal 15.
....


Mit anderen Worten, der WatchDog startet den Pi neu, weil /opt/fhem/log/fhem.heartbeat zu alt, was wahrscheinlich Dein FHEM aktuallisieren soll. Genau zu der Zeit meldet auch das kern.log einen reboot. Also liegt es erstmal scheinbar nicht an der Hardware sondern an FHEM/Watchdog.

Weißt Du noch, mit welchen Zeiten Du den Watchdog konfiguriert hast? Bzw. hast Du den mal abgeschaltet und fhem geprüft?

Übrigens gibt es einen netten Hinweis im syslog:

Code Auswählen Erweitern

Nov 15 17:17:15 raspberrypi ntp[920]: Starting NTP server: ntpd.
Nov 15 17:49:44 raspberrypi systemd[872]: Time has been changed
Nov 15 17:49:44 raspberrypi systemd[1]: Time has been changed


Beim booten wird per ntp Dein PI scheinbar auf die richtige Zeit gesetzt ....

Hinweis:
Mit sinnvoll kürzen hatte ich gemeint, das Du einfach mal die Zeiten rausschneidest. Wie oben zu sehen, steht am Anfang immer das Datum und dann die Uhrzeit. Es wäre in diesem Falle z.B: schon sinnvoll gewesen:

Code Auswählen Erweitern

grep "Nov 15 17:" syslog.log

Edit:
Was mir eben noch aufgefallen ist im bootprozess:

Code Auswählen Erweitern

Nov 15 17:17:03 raspberrypi kernel: [    1.222569] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
....
Nov 15 17:17:03 raspberrypi kernel: [    1.224873] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
....
Nov 15 17:17:03 raspberrypi kernel: [    1.388814] EXT4-fs (mmcblk0p2): recovery complete
Nov 15 17:17:03 raspberrypi kernel: [    1.399135] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
....

Der  Pi hat durch den watchdog einen reboot gemacht, d.h. er sollte sauber runtergefahren sein (oder hast Du es anders Konfiguriert?). Dann ein "recovery" auf dem Dateisystrem nötig? Wird eigentlich nur bei einem unsauberen shutdown (z.B: strom-weg) nötig. Ist Deine SD in Ordnung?

Habe extra meine PIs geprüft, finde bei keinem diese Zeilen. Insofern nehme ich meine erste Aussage, liegt in an Hardware, zurück. Wenn Dein WatchDog einen reinen Software-Restart machen soll (Konfig prüfen!), könntest Du die SDCard tauschen (klonen)?

Legende:
Bei "...." handelt es sich um Sinnvolle Kürzungen, d.h. dort können eine oder mehrere Zeilen stehen

[Invers]

Damit meinst Du das RTC Modul?
Ich hab dieses hier auf jedem PI stecken: https://www.ebay.de/itm/3-3V-5V-DS3231-High-Precision-RTC-Real-Time-Clock-Module-Arduino-Raspberry-Pi/401371719635
Einrichtung: http://www.raspberry-pi-geek.de/Magazin/2015/03/Echtzeituhr-Modul-DS3231-sorgt-fuer-genaue-Zeitangaben

Ah, OK. das ist dann was anderes. Hatte verstanden Du betreibst den PI hinter dem Hub. Der PI darf gerne um die 5,1 Volt vom Netzteil bekommen.
je knapper das Netzteil an den 5V ist umso schneller kann es mal zu tief abrutschen bei Last.

Ahhhh! Vielen Dank. Das habe ich soeben geordert. Danke für den Tipp und den Link  zur Anleitung. Damit sollte selbst ich klarkommen.
Selbst, wenn es nicht daran liegen sollte, ist das auf jeden Fall eine gute Sache. Und Investition kann man das bei dem Preis ja kaum nennen.

[Invers]

Weißt Du noch, mit welchen Zeiten Du den Watchdog konfiguriert hast? Bzw. hast Du den mal abgeschaltet und fhem geprüft?

Derzeit ist der WD abgeschaltet.

Kann ich nicht genau sagen. aber ich bekomme folgende Anzeige bei Statusabfrage:

Code Auswählen Erweitern

pi@raspberrypi:~ $ sudo systemctl status watchdog
● watchdog.service - watchdog daemon
   Loaded: loaded (/lib/systemd/system/watchdog.service; disabled)
   Active: inactive (dead) since Mi 2017-11-15 19:03:27 CET; 14h ago
  Process: 1607 ExecStopPost=/bin/sh -c [ $run_wd_keepalive != 1 ] || false (code=exited, status=1/FAILURE)
  Process: 1077 ExecStart=/bin/sh -c [ $run_watchdog != 1 ] || exec /usr/sbin/watchdog $watchdog_options (code=exited, status=0/SUCCESS)
  Process: 1074 ExecStartPre=/bin/sh -c [ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module (code=exited, status=0/SUCCESS)
Main PID: 1079 (code=exited, status=0/SUCCESS)

Nov 15 18:44:24 raspberrypi watchdog[1079]: watchdog now set to 15 seconds
Nov 15 18:44:24 raspberrypi watchdog[1079]: hardware watchdog identity: Broadcom BCM2835 Watchdog timer
Nov 15 18:44:24 raspberrypi systemd[1]: Started watchdog daemon.
Nov 15 19:02:38 raspberrypi systemd[1]: Started watchdog daemon.
Nov 15 19:03:22 raspberrypi systemd[1]: Stopping watchdog daemon...
Nov 15 19:03:22 raspberrypi watchdog[1079]: stopping daemon (5.14)
Nov 15 19:03:27 raspberrypi systemd[1]: watchdog.service: control process exited, code=exited status=1
Nov 15 19:03:27 raspberrypi systemd[1]: Stopped watchdog daemon.
Nov 15 19:03:27 raspberrypi systemd[1]: Unit watchdog.service entered failed state.
Nov 15 19:03:27 raspberrypi systemd[1]: Triggering OnFailure= dependencies of watchdog.service.

Hinweis:
Mit sinnvoll kürzen hatte ich gemeint, das Du einfach mal die Zeiten rausschneidest. Wie oben zu sehen, steht am Anfang immer das Datum und dann die Uhrzeit. Es wäre in diesem Falle z.B: schon sinnvoll gewesen:

Diese Vorgehensweise war mir nicht bekannt. Da muss ich mich erst mit beschäftigen.

Der  Pi hat durch den watchdog einen reboot gemacht, d.h. er sollte sauber runtergefahren sein (oder hast Du es anders Konfiguriert?). Dann ein "recovery" auf dem Dateisystrem nötig? Wird eigentlich nur bei einem unsauberen shutdown (z.B: strom-weg) nötig. Ist Deine SD in Ordnung?

Habe extra meine PIs geprüft, finde bei keinem diese Zeilen. Insofern nehme ich meine erste Aussage, liegt in an Hardware, zurück. Wenn Dein WatchDog einen reinen Software-Restart machen soll (Konfig prüfen!), könntest Du die SDCard tauschen (klonen)?

Ich habe zur Sicherung folgende Strategie:
Ich besitze 2 Karten, die ich abwechselnd nutze. Karte 1 aus dem Pi wird als Image gespeichert und auf Karte 2 übertragen, die dann in den Pi kommt. Einen Monat später wird umgekehrt verfahren.

Sollte sich im Lauf der Zeit ein Fehler eingeschlichen haben, wird der wahrscheinlich immer wieder mit kopiert.
Es wäre denkbar, dass dann wirklich dieser Fehler zum Absturz führt.
Das war nun meine laienhafte beurteilung.
Ich werde mal versuchen, das Fielesystem zu testen.


Vielen Dank für die Analyse und die Erläuterungen. Hast du gut gemacht, denn ich habe alles auf Anhieb verstanden. 

[Wernieman]

Wenn D eine Kopie hast. kannst Du einfach per "fsck /pfad/zum/Device" prüfen. Die Karte darf dann nicht gemountet sein.

Falls er sagt, Karte muß nicht geprüft werden,  den Schalter "-f" beutzen:
"fsck -f /pfad/zum/Device"

Da ich nicht weiß, wie Du die Karte anschließt, kann ich "/pfad/zum/Device"  für Dich nicht auflösen

[Invers]

Hab mir die Anleitung im Internet gesucht. Hätte ich mal gewartet. Lacht.

Die Karte wurde geprüft und repoariert. der Pi startet wieder mit der repoarierten Karte.
Das war natürlich meine Ersatzinstallation. Die jetzt aktuelle Karte kopiere ich gerade und werde sie dann testen und reparieren.
Danke dir.

[Invers]

Hier das Ergebnis der Reparatur, mal sehen, ob es danach erneut Probleme gibt.
Vorerst danke ich allen fleissigen Helfern.

Code Auswählen Erweitern

pi@raspberrypi:~ $ sudo dosfsck -t -a -w /dev/sda1
fsck.fat 3.0.27 (2014-11-12)
/dev/sda1: 148 files, 2778/7673 clusters
pi@raspberrypi:~ $ sudo fsck.ext4 -Dfty -C 0 /dev/sda2
e2fsck 1.43.3 (04-Sep-2016)
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 3A: Verzeichnisse werden optimiert
Inode 10807 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 14587 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 15311 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 15619 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 30203 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 43404 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 139715 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 156488 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 163993 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 187469 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 187476 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 218246 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Inode 259488 Erweiterung tree (at level 1) could be shorter.  Reparieren? ja

Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft



[Invers]

So, jetzt ist es gerade wieder passiert.
Also: Fhem stürzt nicht ab und der Pi auch nicht.
Der Watchdog hatte den Pi neu gestartet, weil fhem eine lange Zeit blockiert wurde.

Lückenloser Auszug aus dem Log:

Code Auswählen Erweitern

2017.11.22 00:00:12 1: 192.168.178.35:1000 disconnected, waiting to reappear (HMLAN1)
2017.11.22 00:00:12 1: HMLAN_Parse: HMLAN1 new condition disconnected
2017.11.22 00:00:12 1: Perfmon: possible freeze starting at 00:00:01, delay is 11.489
2017.11.22 00:00:12 1: HMLAN_Parse: HMLAN1 new condition init
2017.11.22 00:00:12 1: 192.168.178.35:1000 reappeared (HMLAN1)
2017.11.22 00:00:13 1: HMLAN_Parse: HMLAN1 new condition ok
2017.11.22 00:01:07 3: FBDECT set TVLICHT_vorne off
2017.11.22 00:26:21 1: Perfmon: possible freeze starting at 00:26:20, delay is 1.11
2017.11.22 01:15:15 2: Webradio, cmd error : Die Wartezeit für die Verbindung ist abgelaufen
2017.11.22 01:15:15 2: DI_Radio: set Webradio volume 100: Die Wartezeit für die Verbindung ist abgelaufen
2017.11.22 01:15:15 1: Perfmon: possible freeze starting at 01:15:14, delay is 1.888
2017.11.22 01:19:10 1: Perfmon: possible freeze starting at 01:19:04, delay is 6.386
2017.11.22 01:19:17 1: Perfmon: possible freeze starting at 01:19:11, delay is 6.168
2017.11.22 01:23:00 1: Perfmon: possible freeze starting at 01:20:30, delay is 150.707
2017.11.22 01:23:02 3: FBDECT set LED_Kueche on
2017.11.22 01:23:02 1: Perfmon: possible freeze starting at 01:23:01, delay is 1.802
2017.11.22 01:23:02 1: 192.168.178.35:1000 disconnected, waiting to reappear (HMLAN1)
2017.11.22 01:23:02 1: HMLAN_Parse: HMLAN1 new condition disconnected


Leider lief Apptime nicht. Als es noch lief, hatte ich aber auch für viele Verzögerungen keine Erklärung erhalten. Perfmon zeigte freeze an und Apptime meldete oft gar nichts.

Ich verdächtige das Webradio, welches leider oft Probleme anderer Art macht.

Wir können also festhalten:
Der Watchdog hat ordnungsgemäss funktioniert, Fhem hat ordnungsgemäss funktioniert und der Pi nebst Netzteil also auch.
Einzig das Modul MPD scheint verrückt zu spielen. Muss ich mal sehen, was ich da machen kann, gehört aber in einen anderen Forumsbereich.

Ich danke allen für die zahlreichen Tipps und die intensive Hilfe.

[Wernieman]

Also ich habe auch mpd laufen,. bekomme dort dadurch kein Freez. Bist Du Dir sicher bezüglich Webradio?

[Invers]

Ich nutze mpd mit Webradio-Stationen. Wenn eine davon mal streikt, was leider häufiger der Fall ist, oder wenn meine INet-Verbindung nicht so toll ist, kommt es zu solchen Hängern. Ich habe schon versucht, da drum herum zu programmieren, läuft aber offenbar noch nicht perfekt.

[Wernieman]

?? Habe deshalb noch nie Probleme gehabt. Wenn Stream nicht lief, lief Stream nicht. Fhem war davon nicht beeindruckt. Du hast die aktuelle mpd-Steuerung? Nicht etwa ein veraltetes Modul?

[Invers]

Ich habe die Version :
73_MPD.pm 13247 2017-01-26 20:20:08Z Wzut

[Wernieman]

Also daran sollte es nicht liegen, diese Version ist auch schon "non-blocked", sofern ich weiß ..

Habe die gleiche am laufen:

Code Auswählen Erweitern

73_MPD.pm            13247 2017-01-26 20:20:08Z Wzut

[Invers]

Dann weiss ich leider auch nicht, wo ich noch suchen könnte.
Ich werde mal das Modul auf verbose 5 stellen. Das füllt zwar mein Log gewaltig, aber egal.

Mein Watchdog läuft wieder, habe ich die Reaktionszeit erhöht. Diese liegt nun über dem längsten, bekannten Freeze. Wie gesagt, seitdem habe ich keine Neustarts mehr.

[frank]

du kannst auch mal apptime anschmeissen, ist "schonender" für das log.

[Invers]

Hatte ich weiter oben schon geschrieben, dass ich zu den Freezes meist keinen Eintrag in Apptime bekomme. Zu den Zeiten, wo etwas, das zum Neustart passiert, erfolgte nie ein Eintrag. Ich habe Apptime und Perfmon parallel laufen. Systemlast kann man vernachlässigen. Mein Pi schläft fast ein.