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":
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 0defmod 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:
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.
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.
Zitat von: rudolfkoenig am 17 September 2025, 09:18:40Ich wuerde fhem im Terminal mit "perl fhem.pl (https://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
https://wiki.ubuntuusers.de/Screen/
ZitatOder 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:
$ perl fhem.pl -d fhem.cfg > /media/RAMDisk/debuglog.txt 2>&1
Gilt fuer sh, bash, und verwandte.
Oder screen bzw. eine der Alternativen.
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.