FHEM blockiert immer wieder (in der Regel nachts).

Begonnen von Elektron, 17 März 2026, 21:33:07

Vorheriges Thema - Nächstes Thema

Elektron

Hallo zusammen,

Ich habe seit einiger Zeit das Problem, dass FHEM regelmäßig hängenbleibt und nicht mehr reagiert.
In der Regel passiert es nachts, wenn eigentlich nichts läuft.
In der Zeit, in der das FHEM blockiert ist, erfolgen keine zeitbasierten Steuerungen und auch keine Einträge in Logfiles.
Wenn ich FHEM über ,,sudo systemctl stop fhem" anhalte um es anschließend wieder starte, werden beim Stoppen zeitgesteuerte Aktionen (Rollladen hochfahren bei Sonnenaufgang) ausgeführt.

Ich vermute, dass ein Modul blockiert, habe aber keine Idee herauszufinden welches.
Die Rolladen hängen am KNX (angebunden über einen KNXD), neu hinzugekommen ist eine Anbindung per ModbusTCP (neben der Anbindung per Uart).

Ich bin über jeden Hinweis zur Eingrenzung froh.
Ich habe den DNS-Server als globales Attribut hinterlegt.

Viele Grüße Michael

Sailor

Hallo Elektron

Hatte ein ähnliches Problem.

Bin dann darauf gestoßen, dass ich nachts ein DbLog-Rep ausführe um die Datenbanken zu verschlanken.
Dieser Prozess hatte bei mir damals alles blockiert.

Wenn alles erfolglos geblieben ist hilft nur die brutale Methode:

Backup von der fhem.cfg machen und dann die untere Hälfte löschen.
Schauen obs nochmal auftritt

  Ja: Fehler ist in der oberen  Hälfte
Nein: Fehler ist in der unteren Hälfte

Und entsprechend weiter kürzen und wiederholen

Gruss
    Sailor
******************************
Man wird immer besser...

rudolfkoenig

ZitatWenn ich FHEM über ,,sudo systemctl stop fhem" anhalte um es anschließend wieder starte, werden beim Stoppen zeitgesteuerte Aktionen (Rollladen hochfahren bei Sonnenaufgang) ausgeführt.
"systemctl stop fhem" sendet ein TERM Signal an FHEM, was FHEM aus dem blockierenden Systemaufruf ausreisst.
Der Aufruf liefert einen Fehler, was (falls das betroffene FHEM-Modul geneigt ist) im FHEM-Log protokolliert sein koennte.
=> steht was im FHEM Log?

Und bevor ich die Methode von Sailor zum finden des Fehlers anwende, wuerde ich noch in den Systemlogs schauen (journalctl --since 2026-03-18, vi /var/log/messages, usw.)