Multiple Freezes von FHEM täglich - wie debuggen?

Begonnen von crispinus, 12 November 2020, 19:14:46

Vorheriges Thema - Nächstes Thema

crispinus

Hallo,
ich betreibe insgesamt zwei FHEM-Installationen - eine zu Hause, eine im Betrieb. Die Installation zu Hause läuft schon seit vielen Jahren völlig problemlos und stabil auf einem Embedded-Board im Schaltschrank vor sich hin.
Die Installation im Betrieb läuft auf einem virtualisierten Linuxserver und leidet von Beginn an (d.h. seit etwa 1,5  Jahren) an mehrfach täglich auftretenden Freezes, die letztlich durch einen Reset über das integrierte Watchdog-Modul behoben werden, sodass FHEM dann wieder erreichbar wird. Insbesondere scheint von diesen Freezes das Webinterface betroffen zu sein, während einige Hintergrundprozesse offensichtlich weiter laufen, da einige Automatisierungen auch trotz nicht mehr erreichbarem Webinterface weiter funktionieren.
Updatestand ist der aktuellst verfügbare (heute zuletzt geupdatet), das Problem wurde bisher aber durch kein Update seit Inbetriebnahme verschlimmert oder verbessert. Ich hatte als Auslöser zunächst das SONOS-Modul in Verdacht, weil ich meine, dass die Probleme ursprünglich erst nach Hinzunahme dieses Moduls aufgetreten waren, aber auch ein Umstieg auf eine externe Lösung zur Ansteuerung meiner Sonos-Geräte hat keine Verbesserung gebracht.
Ansonsten ist FHEM im wesentlichen über den knxd mit einem KNX-IP-Interface von MDT verbunden (das gleiche habe ich zu Hause auch problemlos im Einsatz), andere Busse/Geräte sind seit dem Rauswurf des Sonos-Moduls nicht mehr im Einsatz. Es laufen noch diverse DOIFs, die für Automatisierungsaufgaben (Heizungssteuerung, zeitgesteuerte Beleuchtung...) verwendet werden.
Meine Frage ist: wie kann ich am besten herausfinden, an welcher Stelle FHEM hängen bleibt? Das Log gibt hierzu nichts her - hier sehe ich einfach irgendwann den Zeitpunkt, wann FHEM vom Watchdog neugestartet wird, aber keine regelmäßig zuvor auftretenden Logmeldungen.

VG crispinus

Jamo

Hast du im device global den loglevel auf 5 gesetzt (attr global verbose 5)? Damit habe ich mal rausgefunden woher der freeze kam (letzte Zeile im Log).
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/Conbee III, FB7690, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack, Sonos, ESPresence

KölnSolar

freezemon dürfte helfen das Problem darstellen.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

crispinus

Hallo,
vielen Dank für die hilfreichen Lösungsansätze. Über das verbose-Logging konnte ich das Problem mittlerweile auf einen system-Call zurückführen, der ein Kommando ausführte, welches teils recht lange blockierte.
Freezemon hat zu dem Problem übrigens interessanterweise überhaupt nichts gesagt.

VG crispinus