fhem.cfg verschwindet

[passibe]

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.

[Beta-User]

Wenn du DbLog im Verdacht hast: Konfiguration ist OK?
(Man kann das automatisiert checken lassen).

[Hardy74]

Man 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.

[Beta-User]

Man 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!

[betateilchen]

Man 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.

[Hardy74]

indem 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.

[Beta-User]

Es wird aber schon in die DB geschrieben, oder?
Den configCheck zu machen schadet jedenfalls nicht ..

[Icinger]

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.

[Beta-User]

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.

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...

[Hardy74]

Es 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.

Code Auswählen Erweitern

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.

[rudolfkoenig]

plotfork solle in den FHEMWEB auf 1 gesetzt werden

Das ist auch die Voreinstellung, falls man einen Mehrpozessor-CPU unter Linux verwendet.

[Hardy74]

Das 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.

[Hardy74]

@betateilchen

Eben ist fhem ausgestiegen, im Log ohne Zeitstempel einfach nur

Code Auswählen Erweitern

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.

[betateilchen]

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.

Seitdem 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.

[Hardy74]

Reden 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).

Bauchgefü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.