FHEM bleibt "hängen" - wie debuggen?

[TheTrumpeter]

So, seit gestern 22:30 habe ich wieder das gleiche Fehlerbild.

Ich habe nun etwas genauer geschaut. Für mich wirkt es so, als ob der FHEM-Prozess zwar läuft, aber "nichts tut". Die CPU-Last ist permanent "0". Normalerweise verbraucht der Prozess immer mal wieder einzelne Prozent.

Kann ich jetzt noch irgend etwas tun, um dem Problem näher auf die Schliche zu kommen, bevor ich den Prozess wieder neu starte?

[Beta-User]

Was genau meinst Du mit dem ersten Satz?
Irgend etwas, das ich per FHEMWEB selbst verursache?

Nicht mit FHEMWEB, sondern mit FHEM selbst. Typischerweise ist das eine blockierende Datenabfrage von einem entfernten Gerät, das eben gerade nicht erreichbar ist, da das allg. Netzwerk oder nur das entfernte Gerät nicht erreichbar ist. Kann auch ein falsch genutztes "sleep" sein...

Kann ich jetzt noch irgend etwas tun, um dem Problem näher auf die Schliche zu kommen, bevor ich den Prozess wieder neu starte?

Code Auswählen Erweitern

Und dann freezemon oä. anwerfen.
+Lesen, Wiki+Forum nach den gegebenen Schlagworten durchsuchen und selbst aktiv mitdenken... (Niemand hat eigentlich Lust, dieselbe Frage mehrfach zu beantworten. Verständlich, oder?)

[TheTrumpeter]

Freezemon habe ich gestern noch angeworfen, aber vorerst ohne Log. Das hilft mir wohl jetzt nix mehr.

Typischerweise ist das eine blockierende Datenabfrage von einem entfernten Gerät, das eben gerade nicht erreichbar ist, da das allg. Netzwerk oder nur das entfernte Gerät nicht erreichbar ist. Kann auch ein falsch genutztes "sleep" sein...

Da fällt mir nur der Wasserzähler über WMBus ein. Beim "Hänger" vorgestern war dieses Device das Letzte, was geloggt wurde. Mal sehen wie es diesmal war...
Wäre aber dennoch komisch, weil ich von dem Gerät noch nie Verbindungsabbrüche hatte.

"Sleep" habe ich nur in einem benutzerdefinierten Modul im Einsatz, das zum fragwürdigen Zeitpunkt sicher nicht getriggert wurde. Das Modul habe ich aber getestet und hat damals nicht diesen Effekt verursacht. Werde trotzdem nochmal danach schauen.

Kann ich irgendwie herausfinden, ob FHEM grundsätzlich noch reagieren würde, aber eben nur nicht mehr loggt und nicht mehr per FHEMWEB erreichbar ist?

[Beta-User]

Wenn die logs ausbleiben, wartet FHEM auf irgendwas, das kannst du noch 10x fragen...

FHEM ist eigentlich nur ein linear arbeitender single thread. Wartet der, dann werden nur noch geforkte Prozesse abgearbeitet. Aber sonst geht afaik nichts. Ob es möglich ist, FHEMWEB alleine abzuschießen, habe ich ehrlich gesagt noch nie intensiv geprüft, glaube aber wegen des Wesens von FHEM als single thread eigentlich nicht, dass das geht. Würde die Frage also als zwecklos bewerten.

[Wernieman]

FHEM ist, abgesehen von "nonblocking-Modulen" Single-Threaded, d.h. wenn es hängt, dann hängt es komplett.

Du könntst natürlich schauen, ob FHEM z.B. über die telnet-Schnittstelle erreichbar ist ....

Meine Hardcore-Terminalzeiten sind lange vorbei, davor scheue ich mich einfach... abgesehen davon sehe ich nicht, welchen Vorteil das haben soll. Ja, das System ist schlanker und weniger belastet, aber eigentlich langweilt sich der Raspi jetzt auch schon.

Das Problem ist nicht nur die grafische Oberfläche, sondern auch die dazugehörigen Biblioteken, die in Summe ein Sicherheitsrisiko darstellen. Nicht ohne Grund gehen auch die großen Server-Programm-Hersteller (Sogar Microsoft) wieder zur "Terminal" Konfiguration über.

Ich persöhlich finde Terminal sogar einfacher als "Grafische Oberfläche", die meistens sowieso nur ein Überbau über die terminal-Programme ist und damit deren Entwicklerzeit hinterherhängt. In einer Grafischen Oberfläche suche ich mich meistens "zu Tode", bevor ich das Finde, was ich ändern möchte. Gibt allerdings auch Außnahmen (wie FHEM) ....

[TheTrumpeter]

Gut, nach dem Neustart ist der letzte Eintrag im Freezemon vor dem Neustart:

Code Auswählen Erweitern

1 - 2018-12-06: s:22:30:39 e:22:30:40 f:1.465 d:tmr-CustomReadings_OnTimer(mySlowReadings) tmr-TPLinkHS110_Get(LBE250.Steckdose) tmr-FW_closeInactiveClients(N/A)
D.h. eines der 3 genannten Dinge war für eine Freeze-Zeit von 1.5 Sekunden zuständig. Danach sollte FHEM aber wieder "aktiv" gewesen sein.

Ich habe jetzt mal "autocreate" deaktiviert, weil vor ein paar Tagen mal ein unbekanntes WMBus-Device aufgetaucht ist, vermutlich vom Nachbar oder so. Ev. verursacht das Probleme, wenn es kurz erreichbar, dann aber doch nicht, ist?