fhem startet automatisch neu, States werden nicht korrekt oder gar nicht geladen

[Invers]

Bereits 2mal startete fhem nachts neu. Nicht der Pi.
Im Anschluss wurden alle meine Lampen eingeschaltet und die Rollos behaupten, dass sie offen sind. Stimmt aber nicht. Wahrscheinlich stimmen noch andere States nicht. Z.B. mein Dummy, der dokumentiert, dass alle schlafen. Dann sollte gar kein Licht automatisch angehen.
Leider hat meine Frau auf den Taster gedrückt und die Nachtrruhe wieder hergestellt. Daher kann ich nicht alles genau nachvollziehen.

Folgende Infos konnte ich ziehen:
journalctl

Code Auswählen Erweitern

Mär 03 04:39:22 fhem3 systemd[1]: fhem.service: Main process exited, code=exited, status=115/n/a
Mär 03 04:39:22 fhem3 systemd[1]: fhem.service: Failed with result 'exit-code'.
Mär 03 04:39:23 fhem3 systemd[1]: fhem.service: Consumed 2h 40min 27.929s CPU time.
Mär 03 04:39:23 fhem3 systemd[1]: fhem.service: Scheduled restart job, restart counter is at 9.
Mär 03 04:39:23 fhem3 systemd[1]: Stopped FHEM Home Automation.
Mär 03 04:39:23 fhem3 systemd[1]: fhem.service: Consumed 2h 40min 27.929s CPU time.
Mär 03 04:39:23 fhem3 systemd[1]: Starting FHEM Home Automation...
Mär 03 04:39:24 fhem3 systemd[1]: Started FHEM Home Automation.


Mär 06 02:17:06 fhem3 systemd[1]: fhem.service: Main process exited, code=exited, status=115/n/a
Mär 06 02:17:06 fhem3 systemd[1]: fhem.service: Failed with result 'exit-code'.
Mär 06 02:17:06 fhem3 systemd[1]: fhem.service: Consumed 2h 40min 13.590s CPU time.
Mär 06 02:17:06 fhem3 systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
Mär 06 02:17:06 fhem3 systemd[1]: Stopped FHEM Home Automation.
Mär 06 02:17:06 fhem3 systemd[1]: fhem.service: Consumed 2h 40min 13.590s CPU time.
Mär 06 02:17:06 fhem3 systemd[1]: Starting FHEM Home Automation...
Mär 06 02:17:07 fhem3 systemd[1]: Started FHEM Home Automation.


Die Zeile im Log

Code Auswählen Erweitern

Can't locate object method "connect_SSL" via package "IO::Socket::INET" at FHEM/HttpUtils.pm line 512.

kann ich nicht zuordnen, ob vor dem Absturz oder beim Neustart
Danach kommt dann im Log

Code Auswählen Erweitern

2022.03.03 04:39:24.780 3: WEB: port 8083 opened
2022.03.03 04:39:25.739 2: eventTypes: loaded 14970 lines from ./log/eventTypes.txt
2022.03.03 04:39:29.200 3: MQTT2_Server: port 1883 opened

Ist nur der Beginn. Den Rest spare ich mir. Der Neustart halt.

Könnte das an der neuen Configdb liegen?
Wie kann ich denn feststellen, warum fhem abstürzt und neu startret?
Ich sehe keine Auffälligkeiten.
Vielen Dank für Tipps im Voraus.

[KölnSolar]

Ist nur der Beginn

ist der Beginn des restarts. Bei nicht configDB kommt noch die Zeile include 4711.cfg davor.

Can't locate object method "connect_SSL" via package "IO::Socket::INET" at FHEM/HttpUtils.pm line 512

Klingt nach der Absturzursache.

Seltsam finde ich, dass es stundenlang problemlos läuft. Könnte daran liegen, dass auch nur selten eine https-Verbindung aufgerufen wird.

Im Anschluss wurden alle meine Lampen eingeschaltet und die Rollos behaupten, dass sie offen sind. Stimmt aber nicht.

Für FHEM schon. Dein statefile(wo auch immer das bei configDB ist) ist "veraltet". Ich wirke diesem Effekt mit

Code Auswählen Erweitern

define at_FHEM.save at +*00:10:00 {WriteStatefile}entgegen.

Grüße Markus

[Invers]

Fhem läuft mehrere Tage problemlos. So selten können die Aufrufe nicht sein.
States werden ja nun neuerdings in der Configdb gespeichert.
Wenn meine States einfach nur veraltet sind, könnte das ja bedeuten, dass sie nicht aus der Configdb geladen werden, oder nicht in diese gespeichert werden?
Vielleicht kann ja betateilchen was dazu sagen?

[rudolfkoenig]

Can't locate object method "connect_SSL" via package "IO::Socket::INET" at FHEM/HttpUtils.pm line 512

Diese Zeile markiert den Absturz.

Hier wird auf die Initialisierung einer SSL-Verbindung gewartet (FHEM nicht blockierend), und waehrend dieser Zeit ersetzt jemand den Verbindungskenner (aka connection-handle). Das ist vermutlich ein Fehler im aufrufenden Modul, sollte aber im Framework (HttpUtils) abgefangen werden. Das habe ich jetzt gemacht, es wird auch eine Fehlermeldung ausgegeben.

Da ich nicht ganz sicher bin, wo der Verursacher sitzt, interessiert mich weiterhin eine Methode zum Nachstellen.

[Invers]

Vielen Dank.
Leider kann ich nicht viel beitragen. Die einzigen https-Aufrufe sind
define Wetter HTTPMOD https://www.wunderground.com/dashboard/pws/IBEHELLE11 1800\
define Wetter1 HTTPMOD https://www.wunderground.com/dashboard/pws/IBEHELLE11 1800\
define WETTER_WETTER_COM HTTPMOD https://www.wetter.com/deutschland/berlin-hellersdorf/DE0001020090.html 1800
define KalenderH Calendar ical url https://calendar.google.com/calendar/ical...........

Die Wetteraufrufe kann ich nacheinander deaktivieren, falls da der Überltäter sitzt.

Falls die komplette Definition benötigt wird, kann ich sie bereitstellen.

Bei jedem fhem-Start bekomme ich zumindest folgenden Fehler gemeldet:
2022.03.06 10:17:39.690 3: WETTER_WETTER_COM: Read callback: Error: read from https://www.wetter.com:443 timed out
Vor dem Absturz allerdings kommt diese Meldung nicht.

Die Ursache für den Absturz ist also erkannt.
Fehlt noch die Ursache dafür, dass meine States nicht ordentlich wieder hergestellt werden und
die Wonung nachts komplett aktiviert wird, trotz Nachtzeitmarkierung per Dummy, kann man aber damit noch nicht erklären. Und das ist ja das grössere Problem.

[rudolfkoenig]

Fehlt noch die Ursache dafür, dass meine States nicht ordentlich wieder hergestellt werden [...]

FHEM speichert die geaenderten Werte der Geraete nicht automatisch, nur beim ordentlichen Neustart bzw. Beenden des Programmes.
Das hat viele Gruende, unter anderem, dass SD-Karten/USB-Sticks so nicht so schnell kaputtgehen.
Mit einem regelmaessigen Speichern, wie vorhin gezeigt, kann man die Probleme nach einem Absturz begraenzen.
Ob man statt  {WriteStatefile} nicht lieber save verwendet, ist diskussionswuerdig, save vermeidet das Problem, dass fhem.cfg und log/fhem.save unterschiedliche Staende enthalten.

[MadMax-FHEM]

Fehlt noch die Ursache dafür, dass meine States nicht ordentlich wieder hergestellt werden und
die Wonung nachts komplett aktiviert wird, trotz Nachtzeitmarkierung per Dummy, kann man aber damit noch nicht erklären. Und das ist ja das grössere Problem.

Wurde doch schon genannt

Wenn fhem tstächlich "abstürzt" (was ja der Fall ist?), dann wird das state-File nicht geschrieben, bei einem "sauberen" shutdown/restart hingegen schon.

D.h. irgendwann wird das state-File geschrieben (z.B. wenn du eine Config-Änderung speicherst), dann stürzt fhem ab, inzwischen haben sich ja einige Zustände geändert, die stehen (nat.) nicht im state-File.

Daher startet fhem mit den zuletzt GESPEICHERTEN Zuständen nicht mit den zuletzt tatsächlich "vorhandenen" Zuständen...

Daher ja das at mit automatischem Speichern des state-Files von Markus/KölnSolar...

Gruß, Joachim

[Invers]

OK, danke. Habe ich nun verstanden.
Dann werde ich zumindest wenn ich schlafen gehe, das Statefile selber speichern.
Danke allen.

[betateilchen]

States werden ja nun neuerdings in der Configdb gespeichert.
Wenn meine States einfach nur veraltet sind, könnte das ja bedeuten, dass sie nicht aus der Configdb geladen werden, oder nicht in diese gespeichert werden?
Vielleicht kann ja betateilchen was dazu sagen?

Klar, kann ich das...

• states wurden schon immer in der Datenbank gespeichert, wenn der Benutzer die configDB verwendet.
• Dein FHEM-Absturz wegen SSL Problemen hat nichts damit zu tun, ob man mit fhem.cfg oder configDB arbeitet.
• Dass bei einem FHEM Neustart lediglich der zuletzt gespeicherte Zustand Deiner Geräte (readings) wiederhergestellt werden kann, liegt in der Natur der Sache und hat auch nichts damit zu tun, ob man fhem.cfg oder configDB verwendet. Auch das ist schon immer so.

[betateilchen]

Ob man statt  {WriteStatefile} nicht lieber save verwendet, ist diskussionswuerdig, save vermeidet das Problem, dass fhem.cfg und log/fhem.save unterschiedliche Staende enthalten.

Wenn sich die Konfiguration nicht geändert hat, muss man sie auch nicht neu abspeichern.
Dann reicht es, das statefile zu speichern, das dann ja zur unveränderten Konfiguration passt.

(btw & offtopic: was mir in dem Zusammenhang grundsätzlich fehlt, ist eine Möglichkeit, einen shutdown auszuführen, ohne dass das statefile gespeichert wird.)

[Invers]

Klar, kann ich das...

• states wurden schon immer in der Datenbank gespeichert, wenn der Benutzer die configDB verwendet.
• Dein FHEM-Absturz wegen SSL Problemen hat nichts damit zu tun, ob man mit fhem.cfg oder configDB arbeitet.
• Dass bei einem FHEM Neustart lediglich der zuletzt gespeicherte Zustand Deiner Geräte (readings) wiederhergestellt werden kann, liegt in der Natur der Sache und hat auch nichts damit zu tun, ob man fhem.cfg oder configDB verwendet. Auch das ist schon immer so.

Ja, danke für die Antwort.
Bisher war mir in den vielen Jahren nie aufgefallen, dass dies so ist. Nach einem Absturz wurden beim Neustart bisher immer alle Geräte so gelassen, wie sie vor dem Crash geschaltet waren. War offenbar nur Zufall.

SL-Problem war klar, dass nicht die Configdb schuld ist.

Dass der Schaltzustand meiner Geräte so selten gespeichert woird, war mir unbekannt. Ich nahm immer an, dass sofort protokolliert wird.

Naja, man lernt halt nie aus. Danke. Hab nun das AT genutzt, welches alle 30 Minuten das Statefile speichert.

[rudolfkoenig]

(btw & offtopic: was mir in dem Zusammenhang grundsätzlich fehlt, ist eine Möglichkeit, einen shutdown auszuführen, ohne dass das statefile gespeichert wird.)

Code Auswählen Erweitern

define ca_exit cmdalias exit AS {exit(0)}

[betateilchen]

Hilft als cmdalias in meinem Szenario nicht weiter, hat mich aber auf eine andere Lösungsidee gebracht

Danke für den Vorschlag.