Hallo,
ich habe heute ein Update durchgeführt. Danach habe ich folgende Meldungen im Logfile von FHEM gefunden.
2014.03.08 19:31:34 3: update get http://fhem.de/fhemupdate4/svn/FHEM/FhemUtils/release.pm
2014.03.08 19:31:34 1: update check Releases => local: Fhem 5.5 (DEVELOPMENT) remote: Fhem 5.5 (DEVELOPMENT)
2014.03.08 19:31:34 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2014.03.08 19:31:35 1: update saving statefile
2014.03.08 19:31:35 1: backup Can't open configDB: No such file or directory
2014.03.08 19:31:35 2: Backup with command: tar -cf - configDB ./log/fhem.save ./archive ./CHANGED ./configDB.conf ./configDB.conf~ ./configDB.db ./configDB.pm ./contrib ./docs ./FHEM ./fhem.cfg ./fhem.cfg~ ./fhem.pl ./log ./Unbenanntes Dokument~ ./unused ./www |gzip > ./backup/FHEM-20140308_193135.tar.gz
2014.03.08 19:31:54 1: backup tar: configDB: Cannot stat: No such file or directory
tar: ./Unbenanntes: Cannot stat: No such file or directory
tar: Dokument~: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
2014.03.08 19:31:54 1: backup done: FHEM-20140308_193135.tar.gz (33155082 Bytes)
Das Backup scheint also trotzdem gelaufen zu sein und das Update ist dann auch normal gelaufen. Ansonsten läuft mein FHEM ohne Probleme mit der neuen configDB. Was hat das mit diesen Meldungen auf sich? Wenn mehr Angaben benötigt werden bitte melden.
Grüße
Dirk
Wenn jemand mit configDB arbeitet, macht ein Backup z.B. von ./log/fhem.save keinen Sinn mehr, weil die Datei gar nicht mehr beschrieben wird.
Mit dem Backup hab ich mich noch nie beschäftigt, weil ich das vor dem Update ohnehin nicht ausführen lasse.
Ich schau mir das mal an. Ich vermute, dass im backup-Skript irgendwo die als config-Datei gekennzeichnete Datei mit gesichert wird und im Fall der Nutzung von configDB gibt es diese Datei nicht. Stattdessen wird versucht, das Schlüsselwort zu sichern - macht auch keinen Sinn :P
Das Ganze dürfte noch eine generelle Baustelle sein, um die man sich mal kümmern muss. Mein Tipp wäre: schalte das Backup ab oder definiere Dir einen eigenen Backup-Befehl, bis das Problem gelöst ist, wenn es Dich wirklich stört. Das Update selbst sollte aber trotzdem funktionieren.
Der Modulverantwortliche für update und backup hat nun entschieden, die Fehlermeldung dadurch zu beseitigen, dass er configDB Nutzer ab sofort benachteiligt, indem er ihnen die Nutzung der Backup-Funktion einfach komplett verweigert.
Die zu diesem Thema geführte Diskussion kann ab hier nachgelesen werden: Klick mich (http://forum.fhem.de/index.php/topic,20117.msg146973.html#msg146973)
Ich persönlich halte diese Entscheidung weder für sinnvoll noch für begründet und schon gar nicht im Sinne der Anwender.
Deshalb werde ich über eine anwenderfreundlichere Lösung der Aufgabe nachdenken.
Ich schlage allen interessieren Nutzern folgende Lösung vor:
1. Definition eines Alias
define aliasUpdate cmdalias update2 AS configdb backup;;update
2. Ausführen des fhem-Updates mittels des in 1. neu geschaffenen Kommandos update2
Dabei wird zuerst die fhem Installation gesichert, danach das Update durchgeführt.
Zwei Punkte sind zu beachten:
1. Für die Sicherung der benutzten Konfigurationsdatenbank ist der Benutzer grundsätzlich selbst verantwortlich.
2. Falls das Update im Background ausgeführt wird, erfolgt nur eine entsprechende Meldung, aber der EventMonitor zum Mitverfolgen wird nicht aufgerufen.
Wer die Konfigurationsdatenbank in sqlite führt und die Datenbank im fhem Verzeichnis liegen hat, profitiert übrigens von der Einfachheit dieser Datenbank. Denn da sich die gesamte Datenbank in einer einzigen Datei befindet, wird sie als normaler Bestandteil des Verzeichnisses automatisch mitgesichert :)
Sorry für die späte Rückmeldung. Das Backup scheint zu funktionieren. Ich habe wohl nur noch wegen der Erstellung der Datenbank und der conf Datei in Ubuntu mittels sudo noch Zugriffsprobleme. Den ich bekomme immer die Meldung Can't open configDB: No such file or directory
Auf jeden Fall hat FHEM die entsprechenden Rechte und kann schreiben. Und die Datenbank funktioniert und das Backup enthält alle Dateien. Die Rechte bekomme ich dann auch noch in den Griff.
Das ist kein Problem mit der Rechteverwaltung. Wann bekommst Du diese Meldung, und was steht vor oder hinter dieser Meldung im Log?
Ich habe heute das Update gemacht und bekam wieder die Meldung. Dann habe ich noch einmal ein Update (natürlich mit nichts zu tun) mit verbose=5 gefahren. Folgende Ergebnisse habe ich.
- im Loglife erscheint diese Meldung nicht
- die Meldung erscheint bei jedem Update nur auf dem Bildschirm als Abschluss des Vorgangs
Zitat von: dlehmann69 am 15 März 2014, 17:07:45im Loglife
was immer das auch sein mag *g*
Mach mal bitte ein "list global" und poste die Ausgabe hier.
Hier die Ausgabe von configDB list global.
search result for device: global in version: 0
--------------------------------------------------------------------------------
attr global altitude 250
attr global archivedir ./archive/
attr global autoload_undefined_devices 1
attr global holiday2we sachsen
attr global latitude 51.136
attr global logfile ./log/fhem-%Y-%m.log
attr global longitude 13.878
attr global modpath .
attr global nrarchive 1
attr global sendStatistics onUpdate
attr global statefile ./log/fhem.save
attr global uniqueID ./FHEM/FhemUtils/uniqueID
attr global userattr DbLogExclude devStateIcon devStateStyle icon sortby webCmd
attr global verbose 3
Zum einen kann ich mir schwer vorstellen, dass Du wirklich alle fhem-Module auf dem aktuellen Stand hast,
zum zweiten kannst Du mal folgendes Testen:
attr global backup_before_update 0
Solange Du mit dem Standard-Backup von fhem in Kombination mit configDB arbeitest, wirst Du die Fehlermeldung nicht wegbekommen, da Rudi nicht bereit ist, den backup-Prozeß entsprechend anzupassen. Deshalb hatte ich oben bereits die alternative Vorgehensweise beschrieben.
Ich meinte natürlich Logfile von FHEM selbst ;)
Deine Anpassung mit dem eigenen Updatebefehl hatte ich bereits umgesetzt. Trotzdem kam die Meldung nach erfolgtem Update.
Ich habe dann heute ein Update gezogen, nach dem ich das neue Attribute eingefügt habe. FHEM sollte also auf Stand sein. Nach einem Neustart dann noch einmal ein Update gemacht. Die Fehlermeldung bleibt aber wie erwähnt und auch nur auf dem Bildschirm nach dem Update. Im Logfile steht nichts. Das Backup läuft ganz normal durch.
Mich würde mal das Logging des Updates im Filelog selbst interessieren.
Passiert das auch, wenn Du die beiden Schritte getrennt voneinander manuell ausführst (backup + update) ?
backup funktioniert natürlich erwartungsgemäß nicht mit der Meldung not supported for configDB. configdb backup funktioniert ohne Fehlermeldung. Bei update kommt dann auf dem FHEM Bildschirm nach nothing to do die besagte Meldung. Möchtest du die Meldungen aus dem Filelog mit verbose=5? Auf verbose=3 kommt nur folgendes
2014.03.18 21:33:30 3: update get http://fhem.de/fhemupdate4/svn/FHEM/FhemUtils/release.pm
2014.03.18 21:33:30 1: update check Releases => local: Fhem 5.5 (DEVELOPMENT) remote: Fhem 5.5 (DEVELOPMENT)
2014.03.18 21:33:30 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2014.03.18 21:33:30 1: update nothing to do...
Ich habe das Ganze aber auch nochmal mit verbose=5 laufen lassen. Ich sehe da aber keine entsprechende Meldung.
2014.03.18 21:45:51 3: update get http://fhem.de/fhemupdate4/svn/FHEM/FhemUtils/release.pm
2014.03.18 21:45:51 1: update check Releases => local: Fhem 5.5 (DEVELOPMENT) remote: Fhem 5.5 (DEVELOPMENT)
2014.03.18 21:45:51 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2014.03.18 21:45:52 1: update excluded by configuration: HttpUtils.pm
2014.03.18 21:45:52 1: update nothing to do...
Sieht bei mir genau so aus. Nur dass die Fehlermeldung nicht kommt.
Irgendwas muss da bei Dir noch faul sein. Nur hab ich grade keine Idee, was das sein könnte.
Nach dem Update kann es eigentlich keinen Zugriff mehr auf irgendeine Konfigurationsmöglichkeit geben.
Die einzige Möglichkeit, die mir zu der Fehlermeldung einfällt, ist die Möglichkeit, dass irgendwie noch das originale Backup in die Suppe spuckt.
Hast Du den alias wie von mir vorgeschlagen definiert oder daran irgendwas geändert?
Eigentlich wie von dir vorgeschlagen. Hier mal das List aus der DB dazu.
search result for device: aliasUpdate in version: 0
--------------------------------------------------------------------------------
define aliasUpdate cmdalias update2 AS configdb backup;;update
Aber der Fehler kommt ja auch bei dem einzelnen Befehl "update" über das Eingabefeld in FHEM.
mach mal bitte ein "list global" - darum hatte ich schonmal gebeten.
Und ich meine NICHT aus der Datenbank! Einfach nur "list global" eingeben.
Sorry, ich dachte aus der Datenbank. Hier das list global.
Internals:
DEF <no definition>
NAME global
NR 1
STATE <no definition>
TYPE Global
currentlogfile ./log/fhem-2014-03.log
logfile ./log/fhem-%Y-%m.log
CHANGETIME:
Helper:
Dblog:
State:
Mydblog:
TIME 1395143352.39684
VALUE INITIALIZED
Attributes:
altitude 250
archivedir ./archive/
autoload_undefined_devices 1
backup_before_update 0
configfile configDB
holiday2we sachsen
latitude 51.136
logfile ./log/fhem-%Y-%m.log
longitude 13.878
modpath .
nrarchive 1
sendStatistics onUpdate
statefile ./log/fhem.save
uniqueID ./FHEM/FhemUtils/uniqueID
userattr DbLogExclude devStateIcon devStateStyle icon sortby webCmd
verbose 3
version $Id: fhem.pl 5238 2014-03-16 16:23:31Z rudolfkoenig $
komisch komisch... langsam gehen mir die Ideen aus. Aus dem update wird definitiv keine solche Ausgabe geliefert. Und configDB ist auch kein regulärer Dateiname.
Eigentlich sieht es so aus, als ob irgendein Modul auf das globale Attribut configfile zugreift und dann versucht, die dort angegebene Datei zu öffnen. Bisher ist mir ein solches Verhalten nur von 98_backup bekannt, und da wird es korrekt abgefangen.
Welche Module hast Du in Deinem fhem im Einsatz? Mach mal bitte ein "version" um die Liste zu bekommen. Vielleicht fällt mir noch ein "verdächtiges" Modul auf.
ich glaub, ich hab den Übeltäter gefunden...
Kannst Du mal bitte testweise attr global sendStatistics never setzen und dann nochmal probieren?
In 98_fheminfo.pm wird das configfile zum Lesen geöffnet und dann die Fehlermeldung ausgegeben, wenn nicht gelesen werden kann.
Und da Du onUpdate die Statistik sendest, tritt der Fehler vermutlich genau an dieser Stelle auf.
Ja genau das war es. Jetzt kommt die Meldung nicht mehr.
Vielen Dank für die Hilfe.
naja, eine wirkliche Lösung ist es noch nicht, da muss noch eine Anpassung erfolgen.
Die Statistik muss natürlich auch mit configDB funktionieren.
Dauert vermutlich ein paar Tage :)
http://forum.fhem.de/index.php/topic,21588.0.html
Das Problem ist nun beseitigt, die Lösung kommt ab morgen per update.
Dann kannst Du Dein sendStatistics wieder auf "onUpdate" stellen und es sollte auch danach keine Fehlermeldung mehr beim update auftreten.