Sporadisch FHEM-Absturz durch Ausschalten eines verbundenen Clients

[TheTrumpeter]

Ich habe schon länger sporadisch Abstürze von FHEM, deren Ursache ich bisher nicht ergründen konnte.

Im Sommer habe ich dann den RasPi gewechselt (von 3B auf 4B mit 4 GB RAM). Die Abstürze sind seitdem deutlich geringer, treten aber immer wieder "aus dem nichts" auf.

Ich hatte schon länger das Gefühl, dass es durch das Ausschalten meines Stand-PCs "getriggert" wird, d.h. die Abstürze tendenziell dann auftreten, wenn ich diesen Rechner in den Ruhezustand versetze.


Kann ich das irgendwie überprüfen? Das FHEM-Log ist diesbezüglich "leer", da ist nur der Neustart verzeichnet.
Ich habe einen Watchdog im Betriebssystem eingerichtet, der auf die Aktualisierung einer Datei, dessen Zeitstempel ich aus FHEM heraus zyklisch aktualisiere, prüft. Der Watchdog schlägt an, aber warum FHEM "hängt", konnte ich noch nicht herausfinden. Meistens "erfängt" es sich auch nicht mehr von alleine, in seltenen Fällen aber doch.


Tagsüber sind typischerweise mehrere Geräte mit dem Web-Frontend verbunden, das Problem scheint nur von einem der Clients ausgelöst zu werden:
iOS über Safari über "WEBphone" & DynDNS, tendenziell unproblematisch
FireOS über den integrierten Browser über "WEB" & DynDNS, tendenziell unproblematisch
Win-11 über Firefox über "WEB" & externe-IP, tendenziell unproblematisch
Win-10 über Firefox über "WEB" & interne-IP, problematisch

Hier die Definitionen von "WEB" und "WEBphone":

Code Auswählen Erweitern

defmod WEB FHEMWEB IPV6:8083 global
attr WEB HTTPS 1
attr WEB SVGcache 1
attr WEB plotfork 1
attr WEB stylesheetPrefix dark
attr WEB title Georgs FHEM
attr WEB verbose 0

Code Auswählen Erweitern

defmod WEBphone FHEMWEB IPV6:8084 global
attr WEBphone HTTPS 1
attr WEBphone SVGcache 1
attr WEBphone plotfork 1
attr WEBphone stylesheetPrefix darksmallscreen
attr WEBphone title Georgs FHEM
attr WEBphone verbose 0
Hier noch "global" mit anonymisierten GPS-Koordinaten:

Code Auswählen Erweitern

attr global userattr cmdIcon devStateIcon devStateIcon:textField-long devStateStyle icon msgContactAudio msgContactLight msgContactMail msgContactPush msgContactScreen msgParams msgPriority msgRecipient msgRecipientAudio msgRecipientLight msgRecipientMail msgRecipientPush msgRecipientScreen msgRecipientText msgTitle msgTitleShrt msgType:text,push,mail,screen,light,audio,queue powerMap:textField-long powerMap_interval powerMap_noEnergy:1,0 powerMap_noPower:1,0 powerMap_rname_E:textField powerMap_rname_P:textField sortby webCmd webCmdLabel:textField-long widgetOverride
attr global altitude xxx
attr global autoload_undefined_devices 1
attr global autosave 0
attr global dnsServer 10.0.0.138
attr global language DE
attr global latitude xxx
attr global logfile ./log/fhem-%Y-%m.log
attr global longitude xxx
attr global modpath .
attr global motd 1
attr global pidfilename /var/run/fhem/fhem.pid
attr global sslVersion TLSv12:!SSLv3
attr global statefile ./log/fhem.save
attr global verbose 1

Ich sehe gerade, dass ich "verbose" für die FHEMWEB-Instanzen auf 0 gesetzt habe. Werde das mal hochsetzen und weiter beobachten, weitere sachdienliche Hinweise sind gerne willkommen.

[rudolfkoenig]

Verbose fuer FHEMWEB Instanzen zu aendern wird vmtl. nicht die Ursache eines Absturzes verraten, selbst ein "attr global verbose 5" wird nur waage Hinweise geben.
Ich wuerde fhem im Terminal mit "perl fhem.pl -d fhem.cfg" starten, und nach dem Absturz die letzten Zeilen im Terminal inspizieren.

[TheTrumpeter]

Ich wuerde fhem im Terminal mit "perl fhem.pl -d fhem.cfg" starten, und nach dem Absturz die letzten Zeilen im Terminal inspizieren.

Schwierig... ich habe nur Remote-Zugang zu dem RasPi... wenn ich das mache, müsste ich die SSH-Shell permanent verbunden lassen.

Ich kann natürlich versuchen das Ein-/Ausschalten ein paarmal durchzuführen und hoffen, dass es dann auftritt.


Oder würde es funktionieren an den Aufruf noch zusätzlich eine Ausgabe dranzuhängen, also z.B.

perl fhem.pl -d fhem.cfg > /media/RAMDisk/debuglog.txt

[enno]

https://wiki.ubuntuusers.de/Screen/

[rudolfkoenig]

Oder würde es funktionieren an den Aufruf noch zusätzlich eine Ausgabe dranzuhängen, also z.B.

perl fhem.pl -d fhem.cfg > /media/RAMDisk/debuglog.txt

Wichtig ist in diesem Fall auch STDERR umzuleiten:

Code Auswählen Erweitern

$ perl fhem.pl -d fhem.cfg > /media/RAMDisk/debuglog.txt 2>&1
Gilt fuer sh, bash, und verwandte.

Oder screen bzw. eine der Alternativen.

[TheTrumpeter]

OK, Danke für eure raschen Antworten. Das sollte ich hinkriegen, wobei mir auf den ersten Blick die "screen" Variante besser gefällt.

D.h. einfach FHEM beenden, FHEM-Service deaktivieren und über screen und die Shell neu starten.
Und dann warten... zuletzt ist's über 2 Wochen unauffällig gewesen.

[TheTrumpeter]

So, ich habe das mal gestartet... doch ohne "screen", weil ich das auf meinem etwas älteren Raspbian nicht installiert bekommen habe.

Allerdings wird das debug-log sehr schnell sehr groß, ich glaube das wird die RAMDisk voll machen bevor ich was sehe
Muss wohl doch versuchen "screen" zum Laufen zu bekommen.


Was mir auch noch aufgefallen ist:
Das fhem.log wird nun nicht befüllt ((Neu-) Start ist nicht drin), alle anderen Logs scheinen soweit iO zu sein. Ist das erwartet?

[passibe]

auf meinem etwas älteren Raspbian

Vielleicht wäre das mal die erste Baustelle ...
Welche Version läuft denn noch bei dir?

Im Sommer habe ich dann den RasPi gewechselt

Bzw. hast du hier auf dem neuen Pi dann nicht sowieso mit einem frischen System gestartet? Falls nicht, auch wenn das bei Linux vielleicht nicht so kritisch ist, kann es schon sein, dass da noch irgendein "Müll" übrig ist, der dir jetzt Probleme macht.

[TheTrumpeter]

Welche Version läuft denn noch bei dir?

Buster

Bzw. hast du hier auf dem neuen Pi dann nicht sowieso mit einem frischen System gestartet?

Nein erstmal nicht, das gab die Zeit dann nicht mehr her, weil ich beim Umbau Probleme hatte und die Hardware nun doch nicht so ist wie ich das wollte (kombiniertes RS485/RS232-HAT habe ich nicht zum Laufen gebracht, drum läuft RS485 noch/wieder über ein billiges China-USB-Dongle).
Steht aber auf meiner ToDo-Liste.

kann es schon sein, dass da noch irgendein "Müll" übrig ist, der dir jetzt Probleme macht.

Vielleicht habe ich es eingangs nicht verständlich genug ausgedrückt:

Mit dem alten RasPi kam es häufig zu dem Absturz/Neustart, mal mehrmals am Tag, mal alle paar Tage.
Mit dem neuen RasPi beobachte ich es nur noch alle 10-14 Tage.

Ob es wirklich am RasPi liegt oder ich wg. längerem Urlaub nach dem Umbau bisher einfach viel seltener bzw. mit weniger Geräten gleichzeitig verbunden war & das die Ursache ist, kann ich nicht sagen. Allerdings ist der Urlaub auch schon wieder seit 3 Wochen aus und an der oben genannten Frequenz hat sich nix geändert. Mir ist es nur wieder aufgefallen, als ich den Stand-PC abgedreht hatte.
Seit dem Umbau habe ich die Intervalle einiger periodischer Auslese-Prozesse aber auch deutlich verkürzt, d.h. die allgemeine Last ist nun gestiegen.

Was ich "von außen" im Nachhinein (bzw. teilweise auch während dem "Hänger") sehe, lässt mich ratlos zurück.
Selbst wenn FHEM nicht mehr reagiert, kann ich mich problemlos per SSH verbinden, Prozessor- und RAM-Last ist unaufgeregt, das FHEM-service wird als "running" angezeigt, aber es tut nix mehr. Den RasPi selbst musste/habe ich da nie neu gestartet.

[rudolfkoenig]

Das fhem.log wird nun nicht befüllt ((Neu-) Start ist nicht drin), alle anderen Logs scheinen soweit iO zu sein. Ist das erwartet?

Die Option -d setzt verbose level auf 5 und logfile auf - (d.h. STDOUT), damit wird fhem.log nicht mehr befuellt.

[passibe]

Mit dem alten RasPi kam es häufig zu dem Absturz/Neustart, mal mehrmals am Tag, mal alle paar Tage.
Mit dem neuen RasPi beobachte ich es nur noch alle 10-14 Tage.

Ah ok, danke, jetzt verstehe ich.

Hm. Das ist schon dubios. Und es lässt sich wirklich genau auf den Zeitpunkt zurückführen, wenn du den einen Computer ausschaltest? Also diesen:

Win-10 über Firefox über "WEB" & interne-IP, problematisch

Ist der Browser mit der FHEM-Seite immer offen, wenn du ihn in den Ruhezustand versetzt? Was passiert, wenn du nur den Browser schließt, den PC aber an lässt?

Falls es deine Netzwerkinfrastruktur zulässt (wenn Fritzbox, dann unproblematisch möglich): Kannst du eventuell mal von einem anderen Gerät aus den Netzwerkverkehr mitlesen und schauen, ob da irgendwas auffälliges passiert, sobald du den PC in den Ruhezustand versetzt? Auch wenn schwer vorstellbar, könnte es ja sein, dass FHEM auf dem Pi irgendwie versucht den PC noch zu erreichen, das aber nicht mehr kann und dann daran (warum auch immer) kaputtgeht.