[gelöst] Datenverlust: fhem.cfg wird bei "Cannot load module" überschrieben

[Schlimbo]

Hallo zusammen,
ich wollte gerade eine Developer-Version eines Moduls testen, in dieser Version war jedoch noch ein Fehler vorhanden, so dass das Modul nicht geladen werden konnte und nach einem FHEM Neustart folgende Fehlermeldung im Log stand:

Code Auswählen Erweitern

2017.10.30 22:00:15.947 1: configfile: Cannot load module xyz
2017.10.30 22:00:24.323 2: Messages collected while initializing FHEM: configfile: Cannot load module xyz
Kann das Modul nicht geladen werden ist ja klar, dass alle Devices dieses Moduls nicht funktionieren, Sie werden in der Weboberfläche dann auch nicht angezeigt.
Musste jedoch feststellen, dass diese Devices samt ihrer kompletten Konfiguration automatisch aus meiner fhem.cfg gelöscht wurden.
Am Zeitstempel der ConfigFile ist zu sehen, das sie nach dem Neustart verändert wurde:

Code Auswählen Erweitern

FHEM:~$ stat fhem.cfg
  Datei: ,,fhem.cfg"
  Größe: 145048         Blöcke: 288        EA Block: 4096   reguläre Datei
Gerät: b302h/45826d     Inode: 259371      Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--)  Uid: (  999/    fhem)   Gid: (   20/ dialout)
Zugriff    : 2017-10-30 21:38:41.000000000 +0100
Modifiziert: 2017-10-30 22:03:02.084543465 +0100
Geändert   : 2017-10-30 22:03:02.084543465 +0100

Nachstellen kann man das verhalten ganz einfach:
-Zeitstempel der ConfigFile auslesen (stat /opt/fhem/fhem.cfg)
-ein genutztes Modul aus dem Modul-Verzeichnis löschen  ( rm /opt/fhem/FHEM/XYZ.pm}
-FHEM Neustarten
-Zeitstempel der ConfigFile erneut auslesen (stat /opt/fhem/fhem.cfg)

Kann man dieses verhalten irgendwie deaktivieren?
Ich möchte nicht, dass ohne mein zutun irgendjemand in meiner Konfiguration herumpfuscht.

Grüße Schlimbo

[viegener]

Es ist schon prinzipbedingt, dass wenn ein Modul nicht geladen werden kann auch ein define für das Modul nicht durchläuft und dann natürlich der entsprechende deivce nicht angelegt wird. Wenn dann ein save ausgeführt wird ist der device natürlich auch aus der config verschwunden.

Was mich wundert ist, dass bei Dir während des Neustarts ein save ausgeführt wird. Du solltest mal schauen, was diesen save auslöst. Eigentlich ist das die Ursache des Problems bei Dir.

[herrmannj]

attr autosave deaktivieren oder Du hast ein notify etc.

Das nicht laden ist jedenfalls nicht die Ursache sondern das danach gespeichert wurde.

[Beta-User]

Mal ab von der Frage, ob ein potentiell durchgeführtes automatisiertes save Sinn macht (macht es nicht): Ein Wechsel zu configDB könnte -jedenfalls nach meiner Erfahrung - helfen, dann muß man auch nicht bei manuellem Speichern nachsehen, ob nicht irgendwas verloren gegangen ist.

Habe das bisher nirgends ausdrücklich bestätigt erhalten, aber das war das beobachtete Verhalten bei 1-Wire-Devices, wenn Störungen auf dem Bus waren.

Gruß, Beta-User

[kaputt]

Kann man dieses verhalten irgendwie deaktivieren?
Ich möchte nicht, dass ohne mein zutun irgendjemand in meiner Konfiguration herumpfuscht.

Grüße Schlimbo

War die eigentliche Frage welche noch nicht beantwortet wurde.
Extrem ärgerlich bei der Konfig meiner BOSE Lautsprecher das sind rund 130 Zeilen!

[Frank_Huber]

War die eigentliche Frage welche noch nicht beantwortet wurde.
Extrem ärgerlich bei der Konfig meiner BOSE Lautsprecher das sind rund 130 Zeilen!

Das ist beantwortet.
FHEM speichert nicht automatisch!
Das ist per oben genanntem Attribut im global oder in einem notify/DOIF definiert ...

Gesendet von meinem S3_32 mit Tapatalk

[Thorsten Pferdekaemper]

Hi,
seid Ihr Euch da auch ganz, ganz sicher, dass FHEM niemals automatisch speichert? Auf meinem HM-Wired-Entwicklungssystem passiert mir das auch von Zeit zu Zeit, dass die fhem.cfg "kaputtgeht", wenn ich bestimmte Programmierfehler mache. Ich bin dem Effekt bisher nicht nachgegangen, da eine "Reparatur" in dem Fall fast automatisch geht.
Allerdings macht mich der Thread hier etwas stutzig. Vielleicht sollte man das doch ein wenig ernster nehmen.
Gruß,
   Thorsten

[betateilchen]

seid Ihr Euch da auch ganz, ganz sicher, dass FHEM niemals automatisch speichert?

Schauen wir doch einfach mal in die FHEM-Moduldateien...

Überall da, wo CommandSave() ohne Prüfung auf das Attribut autosave ausgeführt wird, könnten Dinge passieren, die nicht beabsichtigt sind.
Aufrufe von "fhem("save ...")" habe ich jetzt noch nicht zusätzlich geprüft.

Code Auswählen Erweitern


~/Development/svn/fhem/FHEM/10_EnOcean.pm:14189:     CommandSave($ctrl, $param);
~/Development/svn/fhem/FHEM/10_EnOcean.pm:15205:     CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/10_EnOcean.pm:15208:     CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/10_OWServer.pm:441:   CommandSave(undef,undef) if( $created && AttrVal($acdname, "autosave", 1 ) );
~/Development/svn/fhem/FHEM/26_tahoma.pm:1011:   CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_HUEBridge.pm:349:       CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_HUEBridge.pm:388:       CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_HUEBridge.pm:557:       CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_HUEBridge.pm:941:     CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_LIGHTIFY.pm:262:           CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_LIGHTIFY.pm:284:       CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_LIGHTIFY.pm:789:       CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_LIGHTIFY.pm:852:       CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/31_HUEDevice.pm:716:       CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/31_Nello.pm:141:             CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/31_Nello.pm:152:             CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/31_Nello.pm:355:             CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/32_withings.pm:748:   CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/32_withings.pm:824:   CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/34_ESPEasy.pm:943:     CommandSave(undef,undef);
~/Development/svn/fhem/FHEM/34_ESPEasy.pm:1350:       CommandSave(undef,undef);
~/Development/svn/fhem/FHEM/34_SWAP.pm:1020:     CommandSave(undef,undef) if( $first && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/36_LaCrosse.pm:356:         CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/36_PCA301.pm:228:     CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/37_harmony.pm:1441:   CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/37_plex.pm:3577:     CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/37_plex.pm:3622:       CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/38_netatmo.pm:2554:   CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/38_netatmo.pm:2661:   CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/38_netatmo.pm:2727:   CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/38_netatmo.pm:2783:   CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/55_PIFACE.pm:368:           CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/55_PIFACE.pm:374:           CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/55_PIFACE.pm:386:           CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/73_NUKIBridge.pm:565:         CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/88_HMCCU.pm:1506: CommandSave (undef, undef) if ($newcount > 0 && $savedef);
~/Development/svn/fhem/FHEM/88_HMCCU.pm:3880: CommandSave (undef, undef);
~/Development/svn/fhem/FHEM/98_autocreate.pm:381:   CommandSave(undef, undef) if(!$ret && $nrcreated &&
~/Development/svn/fhem/FHEM/98_autocreate.pm:622:             CommandSave(undef, undef)
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:643:       CommandSave(undef,undef);
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:767:           $ret .= CommandSave(undef,undef) if (AttrVal($pn,"DOIFtoolsExecuteSave",""));
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:831:       $ret .= CommandSave(undef,undef) if (AttrVal($pn,"DOIFtoolsExecuteSave",""));
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:1074:     CommandSave(undef,undef);
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:1105:         CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:1112:         CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:1354:         $ret = CommandSave(undef,undef) if (AttrVal($pn,"DOIFtoolsExecuteSave",""));
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:1516:       $ret .= CommandSave(undef,undef) if (AttrVal($pn,"DOIFtoolsExecuteSave",""));


[herrmannj]

deja-vu: https://forum.fhem.de/index.php/topic,39985.0.html

seid Ihr Euch da auch ganz, ganz sicher, dass FHEM niemals automatisch speichert?

a: fhem speichert unter den beschriebenen Bedingungen automatisch (by design)
b: kann niemand ausschließen das einzelne modulautoren weitere Funktionen dazu "interpretiert" haben.

Extrem ärgerlich bei der Konfig meiner BOSE Lautsprecher das sind rund 130 Zeilen!

Wer da keine Backup Strategie hat ist selber schuld.

[Benni]

Von den genannten  habe ich mir mal kurz die angeschaut, die ich in Verwendung habe:

34_ESPEasy
98_autocreate.pm

(sind nur die beiden  ) und die sind, soweit ich das sehe kann sauber, das Attribut für autosave wird überprüft.

[dev0]

Schauen wir doch einfach mal in die FHEM-Moduldateien...

Ein simples grep ist wohl eher ungeeignet dazu...

[vbs]

Würde es Sinn machen, einen Befehl "CommandAutoSave" (oder ähnlich) zu haben, welches die Abfrage von dem autosave-Attribut kapselt? Dann müsste sich nicht jedes Modul selbst darum kümmern.

[Thorsten Pferdekaemper]

Warum soll ein Modul überhaupt ein "save" machen dürfen? Ich bin bisher davon ausgegangen, dass so etwas nicht "erlaubt" ist.
Was soll das überhaupt? Meiner Meinung nach hat KEIN Modul (nicht einmal autocreate) jemals an der fhem.cfg herumzufummeln.
Gruß,
   Thorsten

[rudolfkoenig]

Ich habe die Module mit CommandSave angeschaut, da mich die Verwendung in dieser Zahl ueberrascht hat:
- die meisten machen das, wenn sie selbst neue Geraete angelegt haben. Vermutlich war das einfacher, als sich mit dem autocreate Mechanismus auseinanderzusetzen, was ich wiederum schade finde.
- Es gibt auch Faelle, wenn CommandSave nach einem readingsUpdate aufgerufen wird, vermutlich war dem Autor die Funktion WriteStateFile unbekannt.
- manchmal wird vorher das Attribut "global autosave", manchmal "autocreate autosave" und manchmal "TYPE=autocreate autosave" abgefragt. Manchmal aber nicht.
- DOIFtools ist am eifrigsten: wenn definiert, dann wird CommandSave direkt nach dem FHEM-Start, nach global:INITIALIZED ( ??? ) ausgefuehrt.

Das dumme an dem CommandSave ist (vs. AnalyzeCommand(undef, "save") ), dass man es nicht mal mit einem cmdalias umbiegen kann. Angesichts der Meldungen hier und den uebertriebenen Einsatz von CommandSave in den verschiendenen Modulen habe ich vor
- eine automatische Sicherung ala "update" in CommandSave einzubauen, d.h. im restoreDir, zu restaurieren mit restore, wie gewohnt.
- in ComandSave die "global autosave" Option zu pruefen, falls $cl nicht definiert ist (d.h. wenn es nicht wg. Benutzerinteraktion aufgerufen wurde). Achtung: das verhindert ein speichern auch per notify, wenn das Attribut gesetzt ist.

Hat irgendwer Einwaende oder andere Vorschlaege?

[kaputt]

Keine Einwände, aber ....... das ändert nichts daran das Konfigurationen gelöscht werden wenn Module nicht vorhanden sind.
In Verbindung mit "kein editieren der fhem.cfg" muss ich dann meine Definitionen per Webinterface/Telnet rein kloppen.
Könnte man/frau nicht vor dem löschen Fragen? "Kein Modul für Definition XY, löschen ja/nein/vielleicht?"