Moin,
gestern habe ich logdb mit DbLogSelectionMode include eingerichtet. MariaDB läuft auf meinem NAS, die Funktion ist zur Zufriedenheit gegeben.
Fhem läuft seit Jahren auf einem Raspberry in einem Dockercontainer, ebenfalls zur Zufriedenheit.
Seit der Einrichtung von logdb ist fhem nun allerdings bereits 2x "ausgestiegen", meint: der Container versucht fhem neu zu starten, was nicht gelingt, da die fhem.cfg verschwunden ist.
Das erste Mal hier, warum auch immer wird ein Shutdown ausgeführt, der Container versucht fhem neu zu starten, was zunächst auch zu klappen scheint, einige Sekunden später enden jedoch die Logausgaben, 2h später habe ich den Container funktionslos mit fehlender fhem.cfg vorgefunden. Nach Wiederhestellung dieser funktionierte alles wieder. (Der Shelly Networkerror ist ok, der Shelly befindet sich derzeit nicht im Netzwerk).
2025.10.27 13:02:06.062 0: Server shutdown
2025.10.27 13:02:06.070 1: Shutdown executed
2025.10.27 13:02:06.080 2: logdb - stopping SubProcess PID >19042< ...
2025.10.27 13:02:06.125 2: logdb - SubProcess PID >19042< stopped
2025.10.27 13:02:23.538 3: From the FHEM_GLOBALATTR environment: attr global logfile /var/log/fhem/fhem-%Y-%m-%d.log
2025.10.27 13:02:23.539 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2025.10.27 13:02:23.539 3: From the FHEM_GLOBALATTR environment: attr global pidfilename /var/log/fhem/fhem.pid
2025.10.27 13:02:23.539 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2025.10.27 13:02:23.616 1: Including fhem.cfg
2025.10.27 13:02:26.907 2: logdb - Subprocess >28465< initialized ... ready for non-blocking operation
... diverse, übliche Logausgaben
2025.10.27 13:02:55.507 1: [Shelly_status] Device KellerTruhe has Error 'not connected (no route)', state is set to 'Error: Network'
2025.10.27 15:08:10.253 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
Das zweite Mal dann heute Nacht. Nur das hier nach dem nicht gewollten Shutdown nichts mehr passierte. Die letzte Zeile ist die erste heute Morgen, nachdem ich die fhem.cfg wieder hergestellt hatte.
2025.10.28 04:00:00.011 0: Server shutdown
2025.10.28 04:00:00.021 1: Shutdown executed
2025.10.28 04:00:00.042 2: logdb - stopping SubProcess PID >20830< ...
2025.10.28 04:00:00.058 2: logdb - SubProcess PID >20830< stopped
2025.10.28 09:51:32.592 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
Die Fragen liegen auf der Hand:
Wieso wird ein shutdown ausgeführt?
Warum verschwindet die fhem.cfg?
Gibt es einen Zusammenhang zu logdb?
Grüße,
Hartwig
ZitatWieso wird ein shutdown ausgeführt?
Moegliche Ursachen:
- es wurde shutdown eingetippt oder per Web-/DOIF/etc ausgeloest
- Aenderung von attr global encoding
- das PIFACE Modul
- der fhem Process hat SIGTERM bekommen
In diesem Fall vermute ich Letzteres, und wuerde die Linux- bzw. docker-logs pruefen.
ZitatWarum verschwindet die fhem.cfg?
FHEM entfernt das nicht.
Wie wird die Datei dem Container bereitgestellt?
Zitates wurde shutdown eingetippt oder per Web-/DOIF/etc ausgeloest
Auszuschließen. Außer dem logdb habe ich gestern nichts an fhem geändert.
ZitatAenderung von attr global encoding
Habe ich nicht geändert.
Am 21.10. bekam ich diesen Fehler:
2025.10.21 16:26:21.985 3: FHEMWEB WEB CSRF error: csrf_155612548227981 ne csrf_112449131892381 for client WEB_192.168.178.92_59977 / command {sunrise}. For details see the csrfToken FHEMWEB attribute.
und löste das durch den Tip in diesem Post https://forum.fhem.de/index.php?topic=119797.0 durch
attr WEB CORS 0Das ist nun 7 Tage her und macht augenscheinlich keine Probleme.
Zitatdas PIFACE Modul
Kenne ich nicht. Wenn das nicht durch logdb angezogen wird, würde ich auch das ausschließen.
Zitatder fhem Process hat SIGTERM bekommen
In diesem Fall vermute ich Letzteres, und wuerde die Linux- bzw. docker-logs pruefen.
Naheliegende Vermutung, die Systemlogs hatte ich zugegebener Maßen nicht geprüft. SIGTERM finde ich als Text nicht in den Logs, dafür gestern Nachmittag zur besagten Zeit das Folgende. NICHT aber heute Nacht! Weiterhin kommt der Dockerfehler exakt 2Sekunden nach der letzten Logausgabe im fhem log. These, gerne widerlegen: Warum der shutdown überhaupt kommt, sei ersteinmal dahingestellt. Jedoch wird beim Versuch des Startens von fhem die fhem.cfg zermörtelt. Danach findet sie Docker nicht mehr, was zu dem Fehler führt. Warum die fhem.cfg heute morgen wieder weg war, aber keine Fehler im syslog zu finden sind, ist ebenfalls spannend.
Oct 27 13:02:37 raspi2-2 dockerd[625]: time="2025-10-27T13:02:37.051366020+01:00" level=warning msg="Health check for container 919036fa11a41f6c195d139b5b1a4fc0aa21e35fb4ee67c7d24b02f9b67f6b17 error: context deadline exceeded"
Oct 27 13:02:57 raspi2-2 dockerd[625]: time="2025-10-27T13:02:57.076845907+01:00" level=error msg="stream copy error: reading from a closed fifo"
Oct 27 13:02:57 raspi2-2 dockerd[625]: time="2025-10-27T13:02:57.076854314+01:00" level=error msg="stream copy error: reading from a closed fifo"
Oct 27 13:02:57 raspi2-2 dockerd[625]: time="2025-10-27T13:02:57.077300120+01:00" level=warning msg="Health check for container 919036fa11a41f6c195d139b5b1a4fc0aa21e35fb4ee67c7d24b02f9b67f6b17 error: cannot exec in a stopped state: unknown"
Die Container ID gehört zum fhem Container. Da heute Nacht zur fraglichen Zeit kein Error im syslog zu finden ist, wird das ganze nun interessant.
Warum verschwindet eine Datei, wenn sie nicht proaktiv gelöscht wird? Da fällt mir nur ein. dass sie offen ist, in sie geschrieben wird und der Stream dann abbricht.
ZitatWie wird die Datei dem Container bereitgestellt?
Der Ordner /var/opt/fhem ist auf mein NAS gemounted. Das funktioniert seit Jahren einwandfrei und hat den charmanten Vorteil, dass jegliche Änderung an fhem jede Nacht mitgesichert wird. Aufgrund dessen, würde ich dieses Setup als plötzliche Fehlerquelle ausschließen.
Einziger Haken an dem Setup: nach einem Stromausfall kommt fhem nicht alleine aus dem Quark, da ein NAS naturgemäß länger zum Booten benötigt als ein Raspi, das Mounten in diesem Fall dann schief geht.
Wie gesagt, die einzige Änderung gestern war das Hinzufügen von logdb in fhem und auf dem NAS das Installieren des MariaDB Packets in Verbindung mit dem Paket phpMyAdmin.
ZitatHealth check for container ... error: context deadline exceeded
Der Prozess im Container wird gestoppt, falls der Gesundheitscheck nicht ok liefert, die Voreinstellung fuer STOPSIGNAL ist SIGTERM.
Womoeglich hilft es die --health* Parameter fuer diesen Container anzupassen.
Zum Verschwinden der Datei habe ich keine Idee.
shutdown schreibt zwar log/fhem.state, aber nicht fhem.cfg
Moin,
den Grund für den Shutdown um 4Uhr habe ich gefunden:
define ZyklRestart DOIF ([04:00]) (shutdown restart)Das hatte ich irgendwann mal eingebaut, da es gefühlt die Probleme mit HUE geworkaroundet hat. Das ist aber so lange her, dass ich es nicht mehr erinnerte. Meint: der Restart um 4Uhr hat bisher noch nie Probleme gemacht. Die Probleme treten erst jetzt, nach Implementierung von logdb auf. logdb schreibt beim shutdown ja ins log, vielleicht wird in dem Zuge auch die cfg durch logdb geöffnet und nicht wieder geschlossen?
2025.10.30 04:00:00.042 2: logdb - stopping SubProcess PID >32576< ...
2025.10.30 04:00:00.058 2: logdb - SubProcess PID >32576< stopped
Irgendwas schreibt auch unregelmäßig in die fhem.cfg. Ich habe sie in Notepad++ auf und immer wieder fragt mich Notepad++, ob es die veränderte Datei neu laden soll. Ich werden beim nächsten Mal ein Diff machen, was sich denn geändert hat.
Gestern Nacht machte der Neustart keine Probleme, heute Nacht um 4Uhr ist die fhem.cfg wieder verschwunden, ohne Docker- oder sonstige Fehler. Ich werden das zyklische Restarten ersteinmal tot legen, was aber auch nur ein Pflasterkleben statt eines Fixing ist.
Grüße,
Hartwig
Zitatvielleicht wird in dem Zuge auch die cfg durch logdb geöffnet und nicht wieder geschlossen?
Das sollte nicht notwendig sein, und das Oeffnen einer Datei fuehrt auch nicht zum Loeschen.
Damit die Datei weg ist, muss sie jemand explizit entfernt haben.
Idee: vielleicht mit "auditctl" o.Ä. deine fhem.cfg überwachen und so herausfinden, welcher Prozess wann deine fhem.cfg löscht?
ZitatDas sollte nicht notwendig sein, und das Oeffnen einer Datei fuehrt auch nicht zum Loeschen
Bei Windowssystemen ist das eine steile These, ansonsten hätten ja auch Kiosksystem keine Existenzberechtigung, ebenso, wie hieß die Win Variant noch, die ausdrücklich nicht ins Dateinsystem schrieb, embedded? Zu lange her. Bei Linux kenne ich die Historie ehrlich gesagt nicht, Datei öffnen, während des Schreibens Stecker ziehen > wie sieht die Datei danach aus?
Ich würde ausschließen, dass jemand/etwas die Datei explizit löscht.
Letztlich ist dieses Problem auch "nur" ein Seiteneffekt des HUE-Problems. Ich musste fhem soeben händisch neu starten, da Events der HUE Bridge mal wieder nicht durchkamen (wen es interessiert: die motion Events kamen nicht, es kamen nur die nomotion Events -> Licht bleibt aus). Der Neustart klappte, nach dem Neustart von fhem kamen auch wieder alle Events der HUE Bridge bei fhem an.
Leider kümmert sich, nach Aussage von Rudolf, nicht unbedingt jemand mehr um die Probleme mit älteren Modul.
Bei Linux kenne ich die Historie ehrlich gesagt nicht, Datei öffnen, während des Schreibens Stecker ziehen > wie sieht die Datei danach aus?Leer. Aber nicht weg.
Moin,
heute morgen war es mal wieder soweit, was ich leider erst eben bemerkte. fhem war tot, die fhem.cfg verschwunden. Was dieses Mal anders ist: es war kein shutdown, zur Absturzzeit steht im log als letzte Zeile:
Out of memory!
Hier im Forum habe ich diesen Beitrag gefunden https://forum.fhem.de/index.php?topic=121596.msg1162162#msg1162162, in dem auch davon die Rede ist, dass die Konfig "zerschossen" wurde. Leider wird das "Out of memory" nicht erklärt. Auf dem Raspberry ist genug Platz.
Was ist der Grund für "Out of memory!" und warum ist die fhem.cfg danach verschwunden?
Hallo,
bist Du sicher, dass Du genügend physischen Speicher frei hast?
Grüße Jörg
ZitatBist Du sicher, dass Du genügend physischen Speicher frei hast?
Wenn mir df sagt, daß momentan 37% des Speichers benutzt werden, glaube ich das mal. Auch jetzt, nachdem fhem wieder rund 6h läuft.
Zitat von: Hardy74 am 03 November 2025, 16:12:04Out of memory!
Das meint wohl eher den RAM (=Arbeitsspeicher).
df überprüft aber nicht den RAM, sondern den Festplattenspeicher. Wie viel RAM noch frei ist, kannst du mit
free -hüberprüfen. Relevant ist dabei – unintuitiv – nicht der Eintrag bei "free", sondern bei "available".
Zitatdf überprüft aber nicht den RAM, sondern den Festplattenspeicher. Wie viel RAM noch frei ist, kannst du mit
Mein Fehler, du hast natürlich recht! Heute morgen war fhem wieder abgestürzt, incl. Verschwinden der fhem.cfg. free lieferte noch freie ~100MB von 4GB. Das Beenden des fhem containers ließ den verfügbaren Speiche wieder auf 3,7GB steigen. Mit dem Start waren es dann 3.1GB. Seitdem, also etwa seit 4h sind noch 2,8GB verfügbar. Offenbar ist irgendwo ein Speicherleck? Was allerdings auch noch nicht erklärt, warum die fhem.cfg verschwindet.
Es ist offensichtlich, dass fhem, bzw. eines der Module, ein Speicherleck hat. Der angehängte Screenshot zeigt die Speicherauslastung nach ziemlich genau 24h und die Speicherauslastung nach einem shutdown restart.
Mein heißester Kandidat wäre tatsächlich dblog, gefolgt HUE, gefolgt von MQTT2. Es kann natürlich auch ganz woanders liegen und schon lange schlummern, denn, wie oben erwähnt, wurde bis vor kurzem ein tägliches shutdown restart durchgeführt, was das Speicherleck auch kaschiert haben könnte.
Hat jemand ein bewährtes fhem Vorgehen an der Stelle parat, den Übeltäter zu identifizieren? Ansonsten muss ich googeln, um dann wahrscheinlich bei Valgrind&Co zu landen.
Mach mal eine google-Suche mit site:fhem.de Memory Leak, da dürftest du ein paar Threads mit verschiedenen Strategien finden. Ich glaube aber, dass es keine zuverlässigere Methode gibt, als Module eins nach dem anderen zu deaktivieren.
Natürlich vorher auch mal einen Blick in den Event Monitor werfen, usw. Vielleicht ist da ja schon etwas erkennbar.
Wenn du DbLog im Verdacht hast: Konfiguration ist OK?
(Man kann das automatisiert checken lassen).
ZitatMan kann das automatisiert checken lassen
Wie? (Um mir googeln zu ersparen ;) )
An der Defaultkonfig von dblog habe ich nur geändert, dass nur die Readings geloggt werden sollen, die in den jeweiligen Devices explizit dazu eingebunden sind.
Zitat von: Hardy74 am 05 November 2025, 08:50:47ZitatMan kann das automatisiert checken lassen
Wie? (Um mir googeln zu ersparen ;) )
An der Defaultkonfig von dblog habe ich nur geändert, dass nur die Readings geloggt werden sollen, die in den jeweiligen Devices explizit dazu eingebunden sind.
RTFM zu DbLog. Nix Suchmaschine. Doku!
Zitat von: Hardy74 am 05 November 2025, 08:50:47ZitatMan kann das automatisiert checken lassen
Wie? (Um mir googeln zu ersparen
Auch wenn Du offenbar den Unterschied zwischen "jemanden um Hilfe bitten, weil man etwas nicht weiß/versteht" und "jemanden ausnutzen, indem man aus Bequemlichkeit alles vorgekaut haben möchte" nicht kennst, hier zwei Stichworte, die Dir weiterhelfen könnten:
- commandref zu DbLog: https://commandref.fhem.de/#DbLog
- dort insbesondere die Beschreibung zum Befehl: get <name> configCheck
Viel Spaß beim Lesen & viel Erfolg.
Zitatindem man aus Bequemlichkeit alles vorgekaut haben möchte
In dem Fall tatsächlich erwischt.
Wenn ich so darüber nachdenke, habe ich allerdings auch keinen Mehrwert davon, den Übeltäter zu identifizieren. Warum? Das eine sind Zeitgründe, primär aber schlicht Unkenntnis von Perl. Ich bin bei C++ zu Hause, was hier nicht hilft. Im besten Fall könnte ich hier posten, dass es wohl Modul xyz ist, müßte dann aber hoffen, dass irgendjemand, des Perl mächtiger, das dann irgendwann fixt.
Der Workaround des täglichen Restarts hilft in diesem Fall, WENN es denn nicht neuerdings das Problem gäbe, dass die fhem.cfg bei 2 von 3 Neustarts verschwindet und fhem damit alleine natürlich nicht mehr auf die Beine kommt. Da schließt sich dann auch der Kreis zum initialen Grund dieses Threads. Das Memoryleak fiel in diesem Kontext nur mit auf.
Es wird aber schon in die DB geschrieben, oder?
Den configCheck zu machen schadet jedenfalls nicht ..
DBLog und MQTT2 kann ich ausschließen. Mein FHEM läuft seit Jahren stabil (erst auch nem Pi, seit 1.5 Jahren auf nem Docker in Proxmox)
HUE hab ich nix.
Am einfachsten ist es, erstmal alle verdächtigen Module zu disablen und dann Stück für Stück wieder ins Leben zu rufen.
Zitat von: Icinger am 05 November 2025, 18:28:50DBLog und MQTT2 kann ich ausschließen. Mein FHEM läuft seit Jahren stabil (erst auch nem Pi, seit 1.5 Jahren auf nem Docker in Proxmox)
HUE hab ich nix.
Am einfachsten ist es, erstmal alle verdächtigen Module zu disablen und dann Stück für Stück wieder ins Leben zu rufen.
Habe ich beides auch im Einsatz... HUE.* auch lange, war unproblematisch.
DbLog kann für Probleme sorgen, wenn es die gepufferten Daten nicht wegschreiben kann...
ZitatEs wird aber schon in die DB geschrieben, oder?
Den configCheck zu machen schadet jedenfalls nicht ..
Die gewünschten Daten werden anstandslos geloggt. Der Check lieferte u.A plotfork solle in den FHEMWEB auf 1 gesetzt werden. Da es mit fork offenbar Probleme geben kann, wie in anderen Posts zitiert, habe ich das gemacht, ebenso ein fhem update ausgeführt. Weiter werden Zeichensätze angemerkt, wobei hier meine Erwartungshaltung wäre, da automatisch generiert, dass dies auch passt. Das habe ich nicht geändert.
Character Set used by Client (connection): UTF8MB3
Collation used by Client (connection): UTF8MB3_BIN
Character Set used by DB fhem: UTF8MB3
Collation used by DB fhem: UTF8MB3_BIN Da ich tatsächlich auch, in Zusammenhang mit dem dblog, erstmalig mit SVG Plots rumgespielt habe, könnte das ggf. schon geholfen habe. Ich werde das beobachten. Was es aber nicht erklärt, den initialen Grund dieses Posts: das Verschwinden der fhem.cfg
Good news: diverse Neustarts heute, auch hart durch Reboot des Raspis, hat die fhem.cfg überstanden.
Zitatplotfork solle in den FHEMWEB auf 1 gesetzt werden
Das ist auch die Voreinstellung, falls man einen Mehrpozessor-CPU unter Linux verwendet.
ZitatDas ist auch die Voreinstellung, falls man einen Mehrpozessor-CPU unter Linux verwendet.
Das hatte ich beim expliziten Setzen des Attributes gesehen, allerdings war der Check danach zufrieden. Erwartungsgemäß hatte das aber keinen Effekt, der verfügbare Speicher wird nach wie vor langsam aber stetig weniger.
Da ich aus dem Grunde das tägliche Restart wieder enabeln will, überlege ich derzeit, ob ich das Startskript des Containers anpasse, oder aber auf configDB gehe. Mit Letzterer habe ich mich noch nie beschäftigt, Pros, Cons, etc.
@betateilchen
Eben ist fhem ausgestiegen, im Log ohne Zeitstempel einfach nur
DBI connect('database=fhem;host=hdb-nas.fritz.box;port=3306','raspi22',...) failed: Lost connection to MySQL server at 'reading authorization packet', system error: 104 at configDB.pm line 751.
Was kann da die Ursache sein. Seitdem ich dblog nutze hatte ich keine Probleme mehr, auch nicht, nachdem das zyklische Restarten jede Nacht wieder eingebaut habe, als Workaround für das Memoryleak.
Bauchgefühl: ich vermute, Du hast ein lokales Netzwerkproblem.
Die Fehlermeldung kommt jedenfalls nicht aus FHEM, sondern aus dem Betriebssystem.
Hast Du mal Google nach "failed: Lost connection to MySQL server at 'reading authorization packet'" befragt? Dazu gibt es dort jede Menge Ergebnisse.
Zitat von: Hardy74 am 14 November 2025, 18:28:39Seitdem ich dblog nutze hatte ich keine Probleme mehr,
Reden wir jetzt eigentlich über DbLog oder configDB?
Die Fehlermeldung in Deinem letzten Beitrag stammt aus dem versuchten Einsatz von configDB, und das hat nix mit DbLog zu tun.
ZitatReden wir jetzt eigentlich über DbLog oder configDB?
Beides.
Ich hatte dbLog eingeführt, um dedizierte Readings in einer Datenbank zu haben. Das funktionierte auch einwandfrei, löste natürlich das Problem des Speicherlecks und des Verschwindens der fhem.cfg nicht.
Getriggert durch Letzteres habe ich auf configDb umgestellt, was soweit auch problemlos ging und auch bis jetzt auch keine Probleme macht, im Gegenteil! Ich konnte das nächtliche Restart wieder enabeln, als Workaround des Speicherlecks, ohne Angst zu haben, dass die cfg dann wieder weg ist (was auch immer hier der Bösewicht sein mag, die entry.sh des Dockerimages von Git werde ich auch demnächst mal ausmisten.. allerdings lief das jahrelang einwandfrei).
ZitatBauchgefühl: ich vermute, Du hast ein lokales Netzwerkproblem.
Da widerspreche ich nicht. Der Raspberry, auf dem fhem nun im Docker läuft, wie auch der Vorgängerraspberry älteren Modells hatten, sagen wir "Phänomene", die ich lang und breit auch mit AVM bis zur HW runter beleuchtet habe, Ergebnis: keines. Es gibt Hickups, die mit dem neuen Raspi tatsächlich fast 0 geworden sind.
Aber: warum steigt fhem komplett aus, nur weil das Netzwerk weg ist? Ich musste tatsächlich den Container stoppen und starten, um fhem wieder auf die Beine zu helfen. In den Systemlogs leider auch keine Auffälligkeiten.
Offenbar bin ich ja so ziemlich der Einzige, der diese exotischen Probleme hat. Oder bin der Einzige, der sie kommuniziert. Das Speicherleck ist unbestritten, aber (hoffentlich) nicht mein Painpoint, auch hinsichtlich der HUE Kommuniktion, die auch deutlich besser geworden ist (nach "Spülen" der Bridge). Wenn es noch Probleme gibt, dann sind das Verzögerungen, die ich tatsächlich auch, mittlerweile ratlos, im Netzwerk sehe, oder aber fhem ist tot, wie heute.
Zitat von: Hardy74 am 14 November 2025, 23:39:51Aber: warum steigt fhem komplett aus, nur weil das Netzwerk weg ist?
attr global dnsServer gesetzt? Falls nein, setzen und dann neustarten. (Bei docker in der Regel
127.0.0.11.)
Auch sonst kann es Teile der Installation geben, die blocking calls benutzen und dann alles lahmlegen, wenn kein Internet mehr da ist: https://forum.fhem.de/index.php?topic=131807.msg1259723#msg1259723
Erst sollte man feststellen, ob FHEM weg is (d.h. abgestuerzt) oder "nur" verklemmt/blockiert ist.
Im ersten Fall sieht man im FHEM Log vmtl. nicht die Ursache, ich empfehle FHEM aus einem Terminal mit Ausgabe auf diesem Terminal zu starten (perl fhem.pl -d fhem.cfg bzw. perl fhem.pl -d configDB)
"attr global dnsServer" kann im zweiten Fall helfen, muss aber nicht.
Es hilft FHEM blockierungsfrei zu halten, wenn der DNS Server mal klemmt.