FHEM (6.4) startet alle paar Minuten von selbst neu

[andiblueml]

Ich habe FHEM auf einem Raspi aufgesetzt (Raspberry Pi OS bookworm) um einen älteren Rechner für die Haussteuerung zu ersetzen.
Der Server startet alle paar Minuten neu, wie mir im Log aufgefallen ist, schon mit der Startkonfiguration.
Im ausführlichem Log steht:

2025.04.25 16:30:10 5: Starting notify loop for global, 1 event(s), first is SHUTDOWN
2025.04.25 16:30:10 5: End notify loop for global
2025.04.25 16:30:10 0: Server shutdown

mehr leider nicht.
Es ist nie nach einem bestimmten Device oder einer bestimmten Abfrage.

Vielleicht weiß wer was.

Danke

[rudolfkoenig]

Meine Hypothese: irgendwer sendet dem Process ein TERM Signal, vermutlich derjenige, der FHEM danach neu startet.
Was passiert, wenn man FHEM direkt in der Konsole startet?

[andiblueml]

So gestartet läufts.

Es scheint, als würde Systemd keine Starterfolgsmeldung bekommen. Nach nicht ganz 2 Minuten startet er wegen scheinbar fehlendem Erfolg neu. Ich starte mit fhem.service das Standardmäßig installiert wurde (Raspi-Installation mit apt wie empfohlen).
Wie überprüft systemd den Erfolg?

Apr 25 23:32:31 fhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 967.
Apr 25 23:32:31 fhem systemd[1]: Stopped fhem.service - FHEM Home Automation.
Apr 25 23:32:31 fhem systemd[1]: fhem.service: Consumed 1.666s CPU time.
Apr 25 23:32:31 fhem systemd[1]: Starting fhem.service - FHEM Home Automation...
Apr 25 23:34:01 fhem systemd[1]: fhem.service: start operation timed out. Terminating.
Apr 25 23:34:01 fhem systemd[1]: fhem.service: Failed with result 'timeout'.
Apr 25 23:34:01 fhem systemd[1]: Failed to start fhem.service - FHEM Home Automation.
Apr 25 23:34:01 fhem systemd[1]: fhem.service: Consumed 1.660s CPU time.

[Otto123]

Vermutlich blockiert irgendwas beim Start von FHEM und systemd setzt nach 90 sec (defaultwert von systemd) einen Timeout?

Versuch mal diesen Tipp https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)#Restart_verz%C3%B6gern

Aber das ist nur ein Workaround eigentlich muss man der Ursache auf den Grund gehen.

[rudolfkoenig]

Vermutlich blockiert irgendwas beim Start von FHEM und systemd setzt nach 90 sec (defaultwert von systemd) einen Timeout?

Wenn die Uhrzeit noch nicht gesetzt ist (d.h. es wird 1970 gemeldet), dann wartet FHEM zwei Minuten darauf, dass NTP anlaeuft.

Alternativ: in FHEM ist nofork gesetzt, und in der systemd Konfiguration Type=fork.

[Otto123]

Dann könnte aber auch

Code Auswählen Erweitern

Wants=network-online.target
After=network-online.targethelfen? falls ntp nicht blockiert wird und die Zeit beim Start immer auf 1970 steht?
Aber eigentlich dürfte doch dann nur ein Neustart erfolgen, irgendwann läuft ja ntp?

[andiblueml]

Entschuldige die Pause.
Die FHEM-Installation ist in einem Ferienhaus. Diese Woche musste ich arbeiten und der entfernte Login ist etwas tricky, hängt am mobilen Internet.
NTP läuft und lief. Die Zeit stimmt.
Ich hatte tatsächlich nofork=1. Habs auf 0 gesetzt, beobachte was passiert und melde mich.
Mein workaround war, systemd länger Zeit zu geben: in fhem.service TimeoutStartSec=72000 (entspricht 20h) zu setzen. so läuft es zumindest.

Vielen Dank

[betateilchen]

der entfernte Login ist etwas tricky, hängt am mobilen Internet.

Solche Standorte sind bei mir per reverse-ssh Tunnel angebunden, das funktioniert sehr zuverlässig.

[Otto123]

Alternativ: in FHEM ist nofork gesetzt, und in der systemd Konfiguration Type=fork.

Ich hatte tatsächlich nofork=1.

Das ist ja dann wirklich eine Fehlkonfiguration aus Unwissenheit. Könnte dies nicht durch fhem.pl abgefangen werden?
Also beim Start: fhem ermittelt: es wurde durch systemd gestartet, Type= (in der unit) ist simple oder fork -> das attr nofork wird ignoriert und fhem forked
Leider fehlt mir das Wissen um mehr als diese Idee zu formulieren. Vielleicht wird es ja auch zu aufwendig.

[andiblueml]

"nofork" war wohl schuld.
Das ist drin, seit ich diese Config pflege, die läuft schon seit fast 18 Jahren.
Vielen Dank an rudolfkoenig dafür.
Am Anfang war das mal mit drin, da musste ich fhem noch mit init.d starten.
Der Rechner musste nun aufs Altenteil (ein Alix) und wurde durch einen neu aufgesetzten Raspi ersetzt.
Der Reverse SSH-Tunnel war immer etwas instabil. Mit AutoSSH geht das nun stabil.
Dank nochmal an alle.

[rudolfkoenig]

Also beim Start: fhem ermittelt: es wurde durch systemd gestartet, Type= (in der unit) ist simple oder fork -> das attr nofork wird ignoriert und fhem forked

Rauszukriegen, wie man gestartet wurde, und was systemd dabei denkt, ist mir zu fehleranfaellig.
Und ich finde es falsch, Benutzerwuensche zu ignorieren.

[RalfRog]

Vielleicht ne erklärende Ergänzung in der CommandRef?  ...

Rudolf, erst dieser Beitrag hat mich dazu gebracht das Attribut wahrzunehmen und dann durch deinen Hinweis ne Verknüpfung zum systemd zu sehen.

Für mein (unzureichendes) Wissen wäre die CommandRef der richtige Anstoß etwas mehr zu recherchieren.

Gruß Ralf

[rudolfkoenig]

Für mein (unzureichendes) Wissen wäre die CommandRef der richtige Anstoß etwas mehr zu recherchieren.

Ich habe den commandref Eintrag zu nofork aktualisiert.

[Otto123]

Benutzerwuensche

Wobei das in dem Fall ein bisschen dem Wunsch nach Selbsttötung entspricht

Rauszukriegen, wie man gestartet wurde, und was systemd dabei denkt, ist mir zu fehleranfaellig.

Das sehe ich nach etwas Studium mittlerweile auch so, ich dachte heute vormittag noch, jemand sagt: klar mit der API zu systemd ist das ganz einfach.
Die Erklärung in der commandref ist ne gute Sache.