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

[Invers]

Vor einigen Tagen hatte ich hier schon einmal geschrieben, dass mein Pi abstürzt. Als Grund vermutete ich das Netzteil, was sich aber nun leider doch nicht bestätigen liess.
Trotz Erweiterung der Stromversorgung mit einem USB-Hub finden die Abstürze immernoch statt.

Ich habe nun allerdings etwas bemerken können:
Die Uhr wird auf mysteriöse Art zurückgestellt, dann kommt fhem nicht mehr klar damit und blockiert irgendwie. Der Pi würde aber noch weiterlaufen. Mein Watchdog, der fhem beobachtet, schlägt dann aber irgendwann Alarm und der Pi bootet neu. Während des Neustarts von fhem wird dann die Uhr wieder aktualisiert und alles läuft.

Hier mal zum Verständnis einen lückenlosen  Auszug aus dem Log:

Code Auswählen Erweitern

2017.11.14 20:40:00 3: ▀ Abholen angesagt
2017.11.14 20:17:05 3: telnetPort: port 7072 opened
2017.11.14 20:17:06 3: WEB: port 8083 opened
2017.11.14 20:17:06 3: WEBphone: port 8084 opened
2017.11.14 20:17:06 3: WEBtablet: port 8085 opened
2017.11.14 20:17:07 2: eventTypes: loaded 9997 events from ./log/eventTypes.txt
2017.11.14 20:17:08 3: Opening CUL_0 device /dev/serial/by-id/usb-busware.de_CUL868-if00
2017.11.14 20:17:08 3: Setting CUL_0 serial parameters to 9600,8,N,1
2017.11.14 20:17:08 3: CUL_0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2017.11.14 20:17:08 3: CUL_0 device opened
2017.11.14 20:17:08 3: Opening CUL_1 device /dev/serial/by-id/usb-busware.de_CUL433-if00
2017.11.14 20:17:08 3: Setting CUL_1 serial parameters to 9600,8,N,1
2017.11.14 20:17:08 3: CUL_1: Possible commands: ABCEeFGhiKkLlMmRTtUuVWXxY
2017.11.14 20:17:08 3: CUL_1 device opened
2017.11.14 20:17:08 1: HMLAN_Parse: HMLAN1 new condition disconnected
2017.11.14 20:17:08 3: Opening HMLAN1 device 192.168.178.35:1000
2017.11.14 20:17:08 3: Can't connect to 192.168.178.35:1000: Das Netzwerk ist nicht erreichbar
2017.11.14 20:17:13 3: tvabend: Defined with URL http://www.klack.de/fernsehprogramm/2015-im-tv/0/-0/free.html and interval 21600
2017.11.14 20:45:27 3: tvnow: Defined with URL http://www.klack.de/fernsehprogramm/was-laeuft-gerade/0/-1/free.html and interval 1800


Diese Reboots erfolgen zu unterschiedlichen Zeiten und auch an unterschiedlichen Stellen des Logs.

Ich denke auch, dass der Fehler eher in fhem liegen müsste? Die >Uhr wird ja wohl nur softwaremässig emuliert und da wird der Pi ja wohl nichts falsch machen.

Wo könnte ich bei der Suche ansetzen, ohne einen neuen Pi zu kaufen?

[viegener]

Wenn das ein kontinuierlicher Ausschnitt aus Deinem Log ist, hast Du wirklich das Problem schon selber identifziert. Die Zeit auf Deinem pi läuft rückwärts, dass sollte nicht so sein.

Also solltest Du erstmal die Quelle für dieses Rückwärtslaufen identifizieren und ausschalten (ntp ? o.ä.)

Vermutlich läuft dann auch FHEM stabil - ohne verlässliche Uhr wirde es für FHEM schwierig zeitgesteuert zu agieren..

[ComputerZOO]

Moin,
ich hatte mal ein ähnliches Problem. Es hört sich sehr komisch an (war aber so), aber der Pi hatte die falsche NTP-Zeit gezogen (mehrere Male Abweichungen zwischen ein paar Minuten und mehreren Stunden).
Danach habe ich meine FRITZ!Box als NTP-Server eingetragen, seitdem hatte ich damit keine Probleme mehr.
Jetzt kommt wahrscheinlich die Frage: "Woher hat denn die FRITZ!Box ihre Zeit, die zieht sich die ja auch per NTP!" Antwort: "Ich weiß es nicht, wahrscheinlich aus einem anderen NTP-Pool (duck-und-weg)".

[Neuhier]

Ich nehme seit Jahren einen von denen hier:

Code Auswählen Erweitern

ptbtime1.ptb.de
ptbtime2.ptb.de
ptbtime3.ptb.de
Bisher nie Probleme damit gehabt.

[Wernieman]

Wobei das die offiziellen Zeitserver der "Deutschen Zeit" sind. Besser ist, wenn man EIN Gerät sich mit solchen Servern abgleichen lässt, alle anderen sich aber zu dem Konneckten. Wie z.B. die FritzBox. Dort kann man die Zeitserver auch einstellen. Alternativ EINEN Pi (oder Zotac, Synology etc.) zu seinem Zeitserver machen. So kann man auch erst gut Logfiles lesen ....

Was man hier auch sieht:
Es ist nicht immer gut, bei Linux den "Windows-Weg" immer Neuzustarten zu erledigen. Damit wurde hier das Problem nicht gelöst, sondern nur kaschiert. Warum muß ein WatchDog gleich den ganzen Pi durchbooten?

[Neuhier]

Meine Fritte zieht sich das Signal von o.g. Server, die restlichen "Teilnehmer" bekommen das dann von der.

Den RPi dauernd (?) rebooten, wird das System IMHO irgendwann so destabilisieren, daß nix mehr geht.

[Otto123]

Moin,

der Pi arbeitet mit der Zeit normalerweise wie folgt:
fake-hwclock schreibt die Zeit in Abständen (Standard 1h) bzw beim ordentlichen shutdown in eine Datei.
Beim Start vom Pi wird diese Zeit aus der Datei gelesen und als Startzeit übernommen. Sie liegt damit immer in der Vergangenheit, aber normalerweise nicht vorm reboot.
Sobald vom ntp die richtige Zeit kommt wird diese übernommen.

Was man bei Dir sieht ist doch der Neustart!?

Code Auswählen Erweitern

2017.11.14 20:40:00 3: ▀ Abholen angesagt
2017.11.14 20:17:05 3: telnetPort: port 7072 opened

Meine Vermutung: 20:17 hat fake-hwclock das letzte Mal geschrieben
20:40 ist dann das System hart gestorben (wodurch auch immer)
fake-hwclock hat mit 20:17 wieder begonnen
Nach 10 Sekunden fhem wurde die Zeit wieder vom System richtig gesetzt.

Gruß Otto

[Frank_Huber]

Ein Tipp von mir:
steck deinem PI eine RTC auf. gibts für unter 2 Euro inkl Versand bei der großen Bucht...

[Hollo]

Ich nehme seit Jahren einen von denen hier:

Code Auswählen Erweitern

ptbtime1.ptb.de
ptbtime2.ptb.de
ptbtime3.ptb.de
Bisher nie Probleme damit gehabt.

Das macht man eigentlich nicht!
Sinnvoll ist meist die Nutzung einer "Pooladresse" http://www.pool.ntp.org/zone/de.
Die Fritte kann z.B. auch den vom Provider nehmen.

[KölnSolar]

ich glaube eher nicht, dass die "Zeit" die Abstürze beim TE verursacht. Die Zeit ist lediglich Symptom.

Auch ich hatte hier und da Probleme und konnte die selben Symptome beobachten. Die Symptome kommen aber daher, dass der Pi mit einer gespeicherten Zeit bootet. Nun dauert(mal mehr, mal weniger) es etwas bis der Pi sich die neue Zeit geholt hat. Hatte der PI zusätzlich das Problem(oder war einfach noch nicht so weit), dass er beim vorhergehenden "run" die aktuelle Zeit(wohin und wann auch immer) noch nicht geschrieben hat, sieht man nach einem Absturz(also nicht sauberes shutdown) später genau das oben skizzierte Log:

Log-Einträge VOR dem Absturz mit aktueller Zeit, dann der boot nach Absturz mit einer "veralteten" Zeit bis dann der Rpi an die neue Zeit gelangt ist und die Zeiten wieder aktuell sind.

Grüße Markus

[viegener]

Dann würde es auf jeden Fall Sinn machen den watchdog erstmal abzuklemmen, sonst kann man der Ursache der Abstürze nicht auf den Grund gehen. Ausserdem kann es ja sein, dass der watchdog inkorrekterweise annimmt, dass FHEM hängt.

Und wie oben schon gesagt würde ich nicht den pi durchstarten, ist ja kein Windows

[Otto123]

@Markus Sag ich doch -> Die Zeit ist lediglich Symptom.
Ich habe bloß die Erklärung geliefert und diese Vermutung vielleicht nicht so klar ausgesprochen 

[KölnSolar]

Da waren mir die Vorschläge zu ntp-servern, RTC mehr ins Auge gefallen  und ich hab Deine Ausführungen glatt überlesen 
Eine 2. gleiche Meinung schadet ja auch nicht 

[Frank_Huber]

Was mir gerade noch ins Auge fällt:
Du versorgst den PI über einen USB-Hub mit Strom???

falls Ja: besorg Dir ein vernünftiges Raspberry Netzteil! USB-Hubs und Handylader haben keine stabilisierte Spannung.
Damit handelst dir nur Probleme ein.

[Hollo]

...
falls Ja: besorg Dir ein vernünftiges Raspberry Netzteil! USB-Hubs und Handylader haben keine stabilisierte Spannung.
Damit handelst dir nur Probleme ein.

Das kann man nicht pauschal so sagen.
Wie überall gibt es gute und schlechte Netzteile.

Ich habe es umgekehrt gemacht:
Ich versorge mit dem leistungsstarken guten NT, welches ich vorher für den Banana hatte, jetzt den aktiven USB-Hub, und der Banana hängt versorgungsmäßig auch am Hub.
So habe ich definitiv das identische Spannungspotential bei allen Devices und spare sogar ein Netzteil.

[Frank_Huber]

Das kann man nicht pauschal so sagen.
Wie überall gibt es gute und schlechte Netzteile.

Ich habe es umgekehrt gemacht:
Ich versorge mit dem leistungsstarken guten NT, welches ich vorher für den Banana hatte, jetzt den aktiven USB-Hub, und der Banana hängt versorgungsmäßig auch am Hub.
So habe ich definitiv das identische Spannungspotential bei allen Devices und spare sogar ein Netzteil.

Wenn der Hub dann nicht limitiert...
Aber ja, generell geht das schon. Musst halt genau kucken sonst kanns schnell nach hinten los gehen.

Mit dem Handy online, daher kurz gefasst...

[Wernieman]

Wie immer, ist die Frage der Quallität. Es gibt gute und schlechte Netzteile und genau so gute und schlechte USB-Hubs. habe hier 2. An dem einen bekommt der Test-Pi nicht genügend Strom, am anderen läuft er super.

P.S. Qualität <> Preis.

[Invers]

Erst einmal danke ich euch für die wirklich zahlreichen Antworten.

Gerade wollte ich mich ans Werk machen  und alles von oben nach unten beantworten, da stürzt mein Pi erneut ab.
Aber diesmal wurde fhem ordentlich beendet?!?

Log:

Code Auswählen Erweitern

2017.11.15 17:48:56 3: ENIGMA2 set Giga on
2017.11.15 17:49:02 0: ╔══════════════════════════════════════════════════════════════╗
2017.11.15 17:49:02 0: ║ Server shutdown                                              ║
2017.11.15 17:49:02 0: ╚══════════════════════════════════════════════════════════════╝
2017.11.15 17:49:02 0: Server shutdown
2017.11.15 17:49:02 1: Timeout for MPD_IdleStart reached, terminated process 12650
2017.11.15 17:17:05 3: telnetPort: port 7072 opened

Die Meldung im Rahmen habe ich damals eingebaut, damit ich Neustarts besser sehen kann, weil ich so schlecht gucken kann.

Wenn ich einen normalen shutdown mache, kommt also diese Meldung. Hab ich aber nicht. Habe gerade am PC meine Mails gelesen und bin auch erst vor kurzer Zeit nach Hause gekommen.


Manche Tage stürzt fhem gar nicht ab, dann wieder mehrmals täglich, dass nur einmal täglich oder es ist wieder ganz Ruhe. Immer wenn ich denke, nun geht wieder alles, dann haut er wieder einen raus.


@ ComputerZOO
Ich werde die Zeit nun von der Fritzbox holen, obwohl ich auch denke, dass es daran nicht liegt. Aber wenn man verzweifelt ist, probiert man besser alles.

@Wernieman
Ich habe den Watchdog nach hiesiger Anleitung konfiguriert. Es ist der WD des Pi und der startet nun einmal neu. Wie kann man das denn anders machen?

@Otto123
Deine Vermutung ist richtig, hilft aber nicht wirklich weiter.

@Frank_Huber
Das würde/wollte ich bereits sofort tun, aber bei den Modulen, die ich gesehen habe,. muss man noch irgendwelche Bautgeile dazukaufen und löten. Wenn du mir zeigst, welche Teile du genommen hast (Einkaufsliste) und vielleicht noch 3-5 Wörter dazu erklärst, dann mache ich das sofort. Egal, ob die Uhr Schuld hat, oder nicht.

@KölnSolar
Inzwischen bin ich da 100 Prozent deiner Meinung. Ich hatte die Lage leider vorschnell falsch analysiert. Logisch, dass du da Recht hast, denke ich.

@Frank_Huber
Nein, das siehst du falsch. Den Hub nutze ich nur, um die Sticks darüber mit Strom zu versorgen und den Pi somit zu entlasten, damit der sein Netzteil alleine nutzen kann.
Das Netzteil hatte ich bereits vorher erfolglos getauscht, der Fehler blieb.

Nun habe ich so  viele Antworten, weiss aber noch immer nicht, wie ich dem Fehler auf die Spur kommen soll/kann.

Tagelanges loggen ist vielleicht zu viel des Guten. Oder sehe ich das falsch?

Mir ist noch bei  den Zeiten was aufgefallen.
Der Pi startet immer mir

xx:17:05 in der Zeitangabe. also

2017.11.14 20:17:05 3: telnetPort: port 7072 opened
und
2017.11.15 00:17:05 3: telnetPort: port 7072 opened
und
2017.11.15 17:17:05 3: telnetPort: port 7072 opened

Das kann doch kein Zufall mehr sein, oder?

[viegener]

Das mit den Zeiten ist interessant - läuft denn in FHEM irgendetwas

Irgendetwas löst ja den shutdown in Deinem log aus - wenn Du kein at oder sonstiges realisiert hast, vermute ich den watchdog?

Grundsätzlich würde ich aber erstmal den watchdog deaktivieren, denn wie willst Du einen Hänger des Systems finden, wenn immer alle Beweise vernichtet werden (sprich restart). Vielleicht ist nicht FHEM sondern der watchdog Dein Problem

[Wernieman]

Und dann mal in den entsprechenden Zeiten ins kern.log und syslog gucken. (/var/log/....)

z.B. sieht man manchmal auch, was den shutdown ausgelöst hat. Hier z.B. vor 2 Wochen, weil ich beim Aufreumen mit einem Kartong gegen den "Ausschaltknopf" des Zotac gekommen bin ... habe ich nicht gemerkt, aber im Logfile gesehen (ACPI-Event).

Also in diesem Falle, was steht in den Logfiles um den "2017.11.15 17:49:02"?

[KölnSolar]

Aber sind das nicht die "alten" Zeiten, also quasi der letzte "save" von Datum u. Uhrzeit vor dem Absturz ? Und Absturz würde ich es jetzt mal vorsichtig gar nicht nennen, denn der pi-watchdog löst ja aus, wenn ich Dich richtig verstanden habe. Und das tut er warum ?(Hab jetzt nirgends die watchdog-Definition gesehen). Ich spekuliere: weil FHEM eine Datei für den watchdog beschreibt, aber FHEM hängt 
Wenn das zutreffend ist, dann würd ich den watchdog mal rausnehmen, wenn Du anwesend bist, also zeitnah verfolgen kannst, wann FHEM hängt. Dann nicht in Panik neu starten, sondern gucken, ob Du noch mit dem Browser auf FHEM kommst, noch mit telnet/ssh auf den PI kommst, wenn ja, was sagt dann top, fhem status.... wie sehen die timestamps der Logfiles aus, welches Log als letztes geschrieben, welcher timestamp hat das event. Kommst Du gar nicht mehr auf den PI, dann wenigstens noch einen ping probieren......Und vielleicht fallen den anderen noch weitere Prüfungen ein.....

[Invers]

Aber sind das nicht die "alten" Zeiten, also quasi der letzte "save" von Datum u. Uhrzeit vor dem Absturz ? Und Absturz würde ich es jetzt mal vorsichtig gar nicht nennen, denn der pi-watchdog löst ja aus, wenn ich Dich richtig verstanden habe. Und das tut er warum ?(Hab jetzt nirgends die watchdog-Definition gesehen). Ich spekuliere: weil FHEM eine Datei für den watchdog beschreibt, aber FHEM hängt 
Wenn das zutreffend ist, dann würd ich den watchdog mal rausnehmen, wenn Du anwesend bist, also zeitnah verfolgen kannst, wann FHEM hängt. Dann nicht in Panik neu starten, sondern gucken, ob Du noch mit dem Browser auf FHEM kommst, noch mit telnet/ssh auf den PI kommst, wenn ja, was sagt dann top, fhem status.... wie sehen die timestamps der Logfiles aus, welches Log als letztes geschrieben, welcher timestamp hat das event. Kommst Du gar nicht mehr auf den PI, dann wenigstens noch einen ping probieren......Und vielleicht fallen den anderen noch weitere Prüfungen ein.....

Deine Vermutung ist richtig, fhem schreibt eine Datei, auf die dann der WD reagiert. Werde ich sofdort rausnehmen.

Diesen Teil deines Textes verstehe ich leider gar nicht. Kannst du bitte genauer sagen, was da gemeint ist und was ich machen soll?

wenn ja, was sagt dann top, fhem status.... wie sehen die timestamps der Logfiles aus, welches Log als letztes geschrieben, welcher timestamp hat das event.

@viegener
Das werde ich sofort machen.

@Wernieman
Damit bin ich als Linux-Blödel absolut überfordert. Ich hab gerade reingesehen, ist aber leider in englisch und zusätzlich noch alles unverständlich für mich.

Würde sich jemand bereit erklären, die beiden Dateien für mich zu durchforsten, oder ist das sehr aufwändig und somit als Bitte nicht zumutbar? Ich will auch niemanden nerven.

[Otto123]

die Startzeit xx:17:05 hat unter Umständen nichts mit FHEM zu tun. Das ist der cronjob für fake-hwclock. Da hat er das letzte Mal die Zeit festgehalten.

Also Du meinst zwar meine Bemerkung hilft nicht weiter, aber insofern schon: Nicht die Zeitverstellung ist das Problem, dass ist lediglich Symptom.


Gruß Otto

[KölnSolar]

sagte ich doch. Diesmal bist Du "doppelt" 

Diesen Teil deines Textes verstehe ich leider gar nicht. Kannst du bitte genauer sagen, was da gemeint ist und was ich machen soll?

top - ist ein Linux-Befehl der Dir eine Liste über die aktuell leistungsfressenden Prozesse ausgibt
fhem status -  na ja der Aufruf des fhem-Skripts: fhem start/stop/status
timestamps der Logfiles, welches Log als letztes geschrieben  - z.B. mit WinSCP ins Log-Verzeichnis von FHEM gucken. Sortierung absteigend nach Datum/Zeit
timestamp hat das event - z.B. mit WinSCP die Datei(Logfile) öffnen und zum letzten Eintrag scrollen

Edit:

Würde sich jemand bereit erklären, die beiden Dateien für mich zu durchforsten, oder ist das sehr aufwändig und somit als Bitte nicht zumutbar? Ich will auch niemanden nerven.

Stell sie einfach ein(anonymisiert, also keine IP, Passwort...) Wird schon jemand reingucken 

[Otto123]

doppelt erklärt besser 

oder: zwei Formulierungen erklären vielleicht besser 

Eigentlich gibt es aus meiner Erfahrung häufig nur zwei "unklare" Gründe die den pi "abstürzen" lassen: Stromversorgung und "Speicherfresser" 

[Wernieman]

Eigentlich war meine Anmerkung schon ein Angebot, Sie für Dich durchzusehen .. aber bitte "sinnvoll" kürzen und nicht komplett posten

[Invers]

Eigentlich war meine Anmerkung schon ein Angebot, Sie für Dich durchzusehen .. aber bitte "sinnvoll" kürzen und nicht komplett posten

Das wollte ich nicht so unverschämt voraussetzen. Danke dir.
Da ich nicht "sinnvoll" kürzen kann, weil ich ja nichts verstehe, hier mal im Anhang die beidenm kompletten Dateien.
Vielen Dank für deine Mühe im Voraus. Daumendrück.

[Invers]

die Startzeit xx:17:05 hat unter Umständen nichts mit FHEM zu tun. Das ist der cronjob für fake-hwclock. Da hat er das letzte Mal die Zeit festgehalten.

Also Du meinst zwar meine Bemerkung hilft nicht weiter, aber insofern schon: Nicht die Zeitverstellung ist das Problem, dass ist lediglich Symptom.


Gruß Otto

Hatte ich verstanden, wollte ich auch in keinster Weise abwerten. Hab mich wohl blöd ausgedrückt. Ich meinte mehr, dass ich mit dem Tipp mein Problem nicht beseitigen kann.


@KölnSolar
Wieder was gelernt. Top kannte ich gar nicht. Den Rest schon, hatte ich aber tortzdem irgendwie nicht in der äusseren Hirnregion. Natürlich kenne ich fhem start, stop, status. Tja, die Nerven und das Alter.

Beim nächsten Absturz werde ich das alles kontrollieren. Top habe ich schon getestet. Weiss nun, wie das geht.
Danke für deine Geduld, ich weiss, wie es ist, Ahnungslosen etwas vermitteln zu müssen. Lacht.

"Stell sie einfach ein(anonymisiert, also keine IP, Passwort...) Wird schon jemand reingucken"
Ups! Zu spät.

[Frank_Huber]

@Frank_Huber
Das würde/wollte ich bereits sofort tun, aber bei den Modulen, die ich gesehen habe,. muss man noch irgendwelche Bautgeile dazukaufen und löten. Wenn du mir zeigst, welche Teile du genommen hast (Einkaufsliste) und vielleicht noch 3-5 Wörter dazu erklärst, dann mache ich das sofort. Egal, ob die Uhr Schuld hat, oder nicht.

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

@Frank_Huber
Nein, das siehst du falsch. Den Hub nutze ich nur, um die Sticks darüber mit Strom zu versorgen und den Pi somit zu entlasten, damit der sein Netzteil alleine nutzen kann.
Das Netzteil hatte ich bereits vorher erfolglos getauscht, der Fehler blieb.

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.

[viegener]

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.

Es gibt eine Liste von USB-Hubs, die mit dem PI getestet wurden (zum Teil auch zur Versorgung des Pi):
https://elinux.org/RPi_Powered_USB_Hubs

Ich weiss zwar nicht wie gut die Versorgungslage für diese Hubs noch aussieht, denn ich habe die Liste schon vor einiger Zeit aufgetan, aber vielleicht hilft sie ja jemandem, denn es gibt leider immer noch Hubs, die hier Probleme machen (Stichwort back power).

[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.

[Invers]

So, wie versprochen, melde ich hier mal Vollzug.
Ich habe also gestern das Uhr-Modul endlich bekommen. Zu Fuss aus Hong Kong von Mr. Cheung Cha Wan persönlich übergeben, zumindest theoretisch, wenn man die Lieferzeit bedenkt. LOL

Der Einbau (das Aufstecken) des Moduls und die Installation verliefen erfolgreich.
Die o.g. Anleitung ist zwar nicht ganz zutreffend, aber es läuft.

die Eingabe von
sudo update-rc.d ntp disable
verursacht eine Fehlermeldung:
update-rc.d: error: cannot find a LSB script for ntp

Ansonsten alles im grünen Bereich.

Vielen Dank nochmals an die zahlreichen Helfer für ihre Geduld und Unterstützung.