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

Begonnen von Invers, 14 November 2017, 23:07:40

Vorheriges Thema - Nächstes Thema

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:

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?

Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

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


Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

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:
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?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

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

#6
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!?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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

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

Zitat von: Neuhier am 15 November 2017, 08:02:22
Ich nehme seit Jahren einen von denen hier:
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.

FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

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  ???
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

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  ;D
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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

Zitat von: Frank_Huber am 15 November 2017, 10:23:35
...
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.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"