Mir ist jetzt zum 2. Mal hintereinander passiert, dass nach einem update und dem anschließenden Shutdown/Restart alle Werte verloren waren.
Ein 'configdb filelist' zeigt mir mehrere .fhem.save files.
03012c0852dbde726fae7cb5c53f72d2.fhem.save
76a35eb93190d7e29c59b6727cf4bc27 .fhem.save
76a35eb93190d7e29c59b6727cf4bc27.fhem.save
7fff1afc0d14dfc9a08a00aa303d8e6a.fhem.save
b9843beecb0a3e7aba4fe7511d2d74fc.fhem.save
cccf3f9055f7b60f961ba02f6b314bc4 .fhem.save
cccf3f9055f7b60f961ba02f6b314bc4.fhem.save
d0786d90cb4f59997d0fa2dbe740e729 .fhem.save
d0786d90cb4f59997d0fa2dbe740e729.fhem.save
e5452aa0bb1f53dc2793fce66c84e2e4 .fhem.save
e5452aa0bb1f53dc2793fce66c84e2e4.fhem.save
Woher kann ich erkennen, welches der aktuelle Sicherungsfile ist und ob der überhaupt noch beschrieben wird?
Bitte im Titel kennzeichnen, dass es hier um eine configDB Frage geht.
und bitte ins richtige Forum verschieben ;)
ZitatModule: 98_configdb.pm Maintainer: betateilchen Forum: Sonstiges
Zitat von: Otto123 am 14 März 2022, 13:18:51
und bitte ins richtige Forum verschieben ;)
@Otto123: Hier geht es
nicht um 98_configdb.pm
Zitat von: wk am 14 März 2022, 12:11:50
Woher kann ich erkennen, welches der aktuelle Sicherungsfile ist und ob der überhaupt noch beschrieben wird?
Das ist im Moment nicht die wichtigste Frage, sondern das hier:
Zitat von: wk am 14 März 2022, 12:11:50
76a35eb93190d7e29c59b6727cf4bc27 .fhem.save
76a35eb93190d7e29c59b6727cf4bc27.fhem.save
Wir müssen rausfinden, woher die Leerzeichen im Dateinamen beim ersten Eintrag kommen.
Welche Datenbank hast Du im Einsatz?
PostgreSQL
Mach mal bitte ein "attr global verbose 4" und dann ein "save config" - mich interessieren die dann im Logfile auftauchenden Einträge zur configDB.
03012c0852dbde726fae7cb5c53f72d2.fhem.save
1ea46d71d306d6f70d6591acd51fa983.fhem.save
76a35eb93190d7e29c59b6727cf4bc27 .fhem.save
76a35eb93190d7e29c59b6727cf4bc27.fhem.save
7fff1afc0d14dfc9a08a00aa303d8e6a.fhem.save
b9843beecb0a3e7aba4fe7511d2d74fc.fhem.save
cccf3f9055f7b60f961ba02f6b314bc4 .fhem.save
cccf3f9055f7b60f961ba02f6b314bc4.fhem.save
d0786d90cb4f59997d0fa2dbe740e729 .fhem.save
d0786d90cb4f59997d0fa2dbe740e729.fhem.save
e5452aa0bb1f53dc2793fce66c84e2e4 .fhem.save
e5452aa0bb1f53dc2793fce66c84e2e4.fhem.save
neu dazugekommen ist die zweite Zeile. Darin fehlen mir viele Werte.
Grmpf...
Ich versuche ja gerne, Dir zu helfen, das Problem zu lösen.
Aber Du solltest dann bitte auch das tun, worum ich Dich bitte, um dem Fehler auf die Spur zu kommen.
Also nochmal...
Zitat von: betateilchen am 14 März 2022, 13:27:02
Mach bitte ein "attr global verbose 4" und dann ein "save config" - mich interessieren die dann im Logfile auftauchenden Einträge zur configDB.
Genaugenommen interessieren mich nur die ziemlich letzten Einträge, die ungefähr so aussehen:
2022.03.14 13:36:57 4: configDB save state 705c87f182ae4e6f5d74a6780aaba894.fhem.save
2022.03.14 13:36:57 4: configDB writing file: 705c87f182ae4e6f5d74a6780aaba894.fhem.save
2022.03.14 13:36:57 4: configDB save config 705c87f182ae4e6f5d74a6780aaba894
Entschuldige dass ich es nicht so genau genommen habe.
Es wurden 1630 Zeilen geschrieben und die letzten sehen so aus:
2022.03.14 13:35:28 4: configDB save state 1ea46d71d306d6f70d6591acd51fa983.fhem.save
2022.03.14 13:35:28 4: configDB writing file: 1ea46d71d306d6f70d6591acd51fa983.fhem.save
2022.03.14 13:35:28 4: configDB save config 1ea46d71d306d6f70d6591acd51fa983
ok, das sieht erstmal ok aus.
Und jetzt mach mal bitte ein "shutdown restart" und schaue nach dem restart nochmal in das Logfile.
Während des shutdown sollte das statefile nochmal geschrieben werden, beim Neustart muss das dann eingelesen werden.
Mich interessieren wieder die Log-Einträge zur configDB. Das was eingelesen wird, muss das sein, was vorher geschrieben wurde.
Der letzte File, der noch sinnvolle Daten beinhaltet ist der d0786d90cb4f59997d0fa2dbe740e729.fhem.save
OK. hat sich überschnitten. Ich mache, was du sagst
Hallo Udo,
Auch bei mir ist es PostgreSQL und folgende files
15869e0ea40fa976f62c8e2dd28d1097.fhem.save
15869e0ea40fa976f62c8e2dd28d1097 .fhem.save
25d85e16a94cb76eac4cb9a27ee40b01.fhem.save
5cdc578bd03e83575a0b8d77166ac231.fhem.save
767302cf295b19e233e548c332f78e7f.fhem.save
8168b5bd37a549eee3d6703c7c67fc39.fhem.save
8a2ecb09aaf8443d4f440daa3082eb6f.fhem.save
9abae4787aa2b79347cad01d221df750.fhem.save
ab79b65de18f4c2a97fee105de620de0.fhem.save
ab79b65de18f4c2a97fee105de620de0 .fhem.save
ba4c4ef2461472ecbab923f7f265a1de .fhem.save
ba4c4ef2461472ecbab923f7f265a1de.fhem.save
be493482b152641192faaee4ac20f571 .fhem.save
c7a965f50d2b48ef8fc2c8dd4fe023fd .fhem.save
c7a965f50d2b48ef8fc2c8dd4fe023fd.fhem.save
Damit sollte ich wohl das selbige Problem wie der Threadersteller haben
https://forum.fhem.de/index.php/topic,126747.0.html
Das habe ich inzwischen fast vermutet.
Führst Du an irgendeiner Stelle in Deiner Konfiguration ein WriteStatefile manuell aus?
2022.03.14 13:58:50 4: configDB save state 1ea46d71d306d6f70d6591acd51fa983.fhem.save
2022.03.14 13:58:50 4: configDB writing file: 1ea46d71d306d6f70d6591acd51fa983.fhem.save
2022.03.14 13:58:50 4: WEB: /fhem?XHR=1&cmd=shutdown%20restart&fw_id=2665 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate
2022.03.14 13:58:51 4: configDB read config 1ea46d71d306d6f70d6591acd51fa983
2022.03.14 13:58:51 4: configDB reading file: 1ea46d71d306d6f70d6591acd51fa983 .fhem.save
2022.03.14 13:58:51 4: configDB read state from table fhemstate
2022.03.14 13:58:51 4: configDB reading file: /opt/fhem/FHEM/FhemUtils/uniqueID
2022.03.14 13:58:51 3: WEB: port 8083 opened
2022.03.14 13:58:51 4: configDB reading file: /var/log/fhem/eventTypes.txt
2022.03.14 13:58:51 2: eventTypes: loaded 6274 lines from /var/log/fhem/eventTypes.txt
2022.03.14 13:58:51 4: configDB reading file: /opt/fhem/db.conf
2022.03.14 13:58:50 4: configDB save state 1ea46d71d306d6f70d6591acd51fa983.fhem.save
2022.03.14 13:58:50 4: configDB writing file: 1ea46d71d306d6f70d6591acd51fa983.fhem.save
2022.03.14 13:58:51 4: configDB read config 1ea46d71d306d6f70d6591acd51fa983
2022.03.14 13:58:51 4: configDB reading file: 1ea46d71d306d6f70d6591acd51fa983 .fhem.save
2022.03.14 13:58:51 4: configDB read state from table fhemstate
Ok, danke, das hilft mir weiter.
Das Problem tritt nicht beim Schreiben auf, sondern beim Lesen.
Holt Euch mal einen Kaffee und gebt mir 10 Minuten Zeit.
Das Problem scheint darin zu liegen, dass ein Rückgabewert aus einer Datenbanktabelle, in der das Feld mit 50 Zeichen Länge angelegt ist, am Ende mit Leerzeichen aufgefüllt von der Datenbank zurückgegeben wird. Daraus resultiert dann ein Dateiname mit vielen Leerzeichen, den es natürlich nicht gibt. Deshalb werden keine states geladen.
In SVN gibt es eine neue Version von configDB.pm, die den Dateinamen links und rechts bearbeitet, sodaß da keine Leerzeichen mehr stehen sollten.
# $Id: configDB.pm 25836 2022-03-14 13:19:34Z betateilchen $
Kann das bitte jemand von Euch testen und berichten?
Grundsätzlich kann ich solche Änderungen an configDB in mysql und sqlite selbst testen, aber nicht in postgresql.
Auch bei den Testern, die mir während der Entwicklung geholfen haben, war offenbar niemand mit diesem Datenbanktyp dabei, sonst wäre das früher aufgefallen.
Wenn ich das nächste Mal um Testbenutzer bitte, wäre es schön, wenn sich jemand von Euch meldet :)
Zitat von: betateilchen am 14 März 2022, 14:05:46
Das habe ich inzwischen fast vermutet.
Führst Du an irgendeiner Stelle in Deiner Konfiguration ein WriteStatefile manuell aus?
Nein nie
die Frage hatte sich bereits erledigt :)
Zitat von: betateilchen am 14 März 2022, 14:11:19
Das Problem tritt nicht beim Schreiben auf, sondern beim Lesen.
Ich habe die aktuelle Version installiert und getestet. Bei mir wird nun der State nach einem Neustart behalten. Auch ein save und anschließender neustart klappt ohne Probleme. In meinen Augen erstmal gelöst.
Vielen Dank Udo.
Grüße
Wenn das so klappt, kann ich dann eine ältere xxxx.fhem.save wieder einspielen, oder muss ich alles noch einmal eingeben?
Ich habe jetzt eine Weile gebraucht bis ich meinen Fehler begriffen habe:
ZitatconfigDB
[EN DE]
configDB ist die Funktionsbibliothek für die Konfiguration aus einer SQL Datenbank.
Die ausführliche Dokumentation findet sich in der configdb Befehlsbeschreibung.
configdb
Leider keine deutsche Dokumentation vorhanden. Die englische Version gibt es hier: configdb
ich versuche immer mit help ... die entsprechende Info zu finden. help unterscheidet nicht zwischen configdb und configDB - daher mein Zitat.
Zitat von: Otto123 am 14 März 2022, 14:45:54
Ich habe jetzt eine Weile gebraucht bis ich meinen Fehler begriffen habe
Musst Du jeden Thread zugrunde richten?
Das hat doch jetzt überhaupt nichts mit meiner Hilfestellung zu tun, die ich hier gerade leiste.
Zitat von: CoolTux am 14 März 2022, 14:40:39
Ich habe die aktuelle Version installiert und getestet. Bei mir wird nun der State nach einem Neustart behalten. Auch ein save und anschließender neustart klappt ohne Probleme. In meinen Augen erstmal gelöst.
Danke für die Info.
Zitat von: wk am 14 März 2022, 14:44:11
Wenn das so klappt, kann ich dann eine ältere xxxx.fhem.save wieder einspielen, oder muss ich alles noch einmal eingeben?
Melde Dich mal bitte per email
Bevor uns hier wieder jemand unqualifiziert dazwischenquatscht, lösen wir das lieber außerhalb des Forums.
Dank Udos Hilfe läuft wieder alles wie gewünscht.
Vielen Dank
Walter
Kurze Frage. Wie lösche ich am besten die falschen Dateinamen. Also die mit den vielen Leerzeichen.
Mach mal "configdb reorg", da sollten alle statefiles verschwinden, zu denen es keine gespeicherte Konfiguration gibt.
Zitat von: betateilchen am 14 März 2022, 17:08:13
Mach mal "configdb reorg", da sollten alle statefiles verschwinden, zu denen es keine gespeicherte Konfiguration gibt.
Interessant, jetzt ist gar kein fhem.save mehr da 😁
Das scheint das nächste postgresql spezifische Problemverhalten zu sein 8)
Diesmal aber umgekehrt, bei der Suche fehlen die Leerzeichen...
@CoolTux kannst Du mal bitte mit der Version in ./contrib/betateilchen/debug testen?
mehrere Konfigurationen speichern, dann ein "configdb reorg"
Die debug-Version löscht keine Daten, sie schreibt nur ein paar Einträge ins Logfile, die mir helfen, zu verstehen, was da passiert.
Zitat von: betateilchen am 14 März 2022, 17:59:57
@CoolTux kannst Du mal bitte mit der Version in ./contrib/betateilchen/debug testen?
mehrere Konfigurationen speichern, dann ein "configdb reorg"
Die debug-Version löscht keine Daten, sie schreibt nur ein paar Einträge ins Logfile, die mir helfen, zu verstehen, was da passiert.
Mit der Version aus contrib funktioniert der reorg Befehl. Die fhem.save hashfiles sind diesmal erhalten geblieben.
Zitat von: CoolTux am 14 März 2022, 19:53:01
Mit der Version aus contrib funktioniert der reorg Befehl.
Nein, tut es nicht...
Zitat von: betateilchen am 14 März 2022, 17:59:57
Die debug-Version löscht keine Daten, sie schreibt nur ein paar Einträge ins Logfile, die mir helfen, zu verstehen, was da passiert.
ich brauche bitte die Logeinträge aus dem configdb reorg.
2022.03.14 19:51:45 1: file: >ce84bcb1657860b682c8723302028941.fhem.save<
2022.03.14 19:51:45 1: uuid: >ce84bcb1657860b682c8723302028941<
2022.03.14 19:51:45 1: found: >ce84bcb1657860b682c8723302028941 <
2022.03.14 19:51:45 1: del >ce84bcb1657860b682c8723302028941.fhem.save<
2022.03.14 19:51:45 1: file: >c3f569c4c8d00d223f8598815ba7f831.fhem.save<
2022.03.14 19:51:45 1: uuid: >c3f569c4c8d00d223f8598815ba7f831<
2022.03.14 19:51:45 1: found: >c3f569c4c8d00d223f8598815ba7f831 <
2022.03.14 19:51:45 1: del >c3f569c4c8d00d223f8598815ba7f831.fhem.save<
2022.03.14 19:51:45 1: file: >4e66083ca955e7c956ff1f3b2f787cf6.fhem.save<
2022.03.14 19:51:45 1: uuid: >4e66083ca955e7c956ff1f3b2f787cf6<
2022.03.14 19:51:45 1: found: >4e66083ca955e7c956ff1f3b2f787cf6 <
2022.03.14 19:51:45 1: del >4e66083ca955e7c956ff1f3b2f787cf6.fhem.save<
und heute morgen vom täglichen aufräumen durch ein at
2022.03.15 01:30:01 1: file: >ce84bcb1657860b682c8723302028941.fhem.save<
2022.03.15 01:30:01 1: uuid: >ce84bcb1657860b682c8723302028941<
2022.03.15 01:30:01 1: found: >ce84bcb1657860b682c8723302028941 <
2022.03.15 01:30:01 1: del >ce84bcb1657860b682c8723302028941.fhem.save<
2022.03.15 01:30:01 1: file: >c3f569c4c8d00d223f8598815ba7f831.fhem.save<
2022.03.15 01:30:01 1: uuid: >c3f569c4c8d00d223f8598815ba7f831<
2022.03.15 01:30:01 1: found: >c3f569c4c8d00d223f8598815ba7f831 <
2022.03.15 01:30:01 1: del >c3f569c4c8d00d223f8598815ba7f831.fhem.save<
2022.03.15 01:30:01 1: file: >4e66083ca955e7c956ff1f3b2f787cf6.fhem.save<
2022.03.15 01:30:01 1: uuid: >4e66083ca955e7c956ff1f3b2f787cf6<
2022.03.15 01:30:01 1: found: >4e66083ca955e7c956ff1f3b2f787cf6 <
2022.03.15 01:30:01 1: del >4e66083ca955e7c956ff1f3b2f787cf6.fhem.save<
2022.03.15 01:30:01 3: at_ConfigDBreorg: Result after database reorg:
super, danke. Wir kommen der Sache näher :)
Kannst Du bitte nochmal mit der Version testen, die ich eben eingecheckt habe?
Auch diese Version simuliert das Löschen nur und protokolliert das im Log.
Wenn das Ergebnis gut aussieht, kommt heute noch eine offizielle Version, die dann auch wieder tatsächlich löscht.
2022.03.15 10:22:49 1: file: >0ad9eeadde78f997aa99b62bb88bcd11.fhem.save<
2022.03.15 10:22:49 1: uuid: >0ad9eeadde78f997aa99b62bb88bcd11<
2022.03.15 10:22:49 1: found: >0ad9eeadde78f997aa99b62bb88bcd11 <
2022.03.15 10:22:49 1: found: >0ad9eeadde78f997aa99b62bb88bcd11<
2022.03.15 10:22:49 1: file: >ce84bcb1657860b682c8723302028941.fhem.save<
2022.03.15 10:22:49 1: uuid: >ce84bcb1657860b682c8723302028941<
2022.03.15 10:22:49 1: found: >ce84bcb1657860b682c8723302028941 <
2022.03.15 10:22:49 1: found: >ce84bcb1657860b682c8723302028941<
2022.03.15 10:22:49 1: file: >c3f569c4c8d00d223f8598815ba7f831.fhem.save<
2022.03.15 10:22:49 1: uuid: >c3f569c4c8d00d223f8598815ba7f831<
2022.03.15 10:22:49 1: found: >c3f569c4c8d00d223f8598815ba7f831 <
2022.03.15 10:22:49 1: found: >c3f569c4c8d00d223f8598815ba7f831<
2022.03.15 10:22:49 1: file: >4e66083ca955e7c956ff1f3b2f787cf6.fhem.save<
2022.03.15 10:22:49 1: uuid: >4e66083ca955e7c956ff1f3b2f787cf6<
2022.03.15 10:22:49 1: found: >4e66083ca955e7c956ff1f3b2f787cf6 <
2022.03.15 10:22:49 1: found: >4e66083ca955e7c956ff1f3b2f787cf6<
Bitte schön
danke, das sieht gut aus.
Die neue offizielle Version ist eingecheckt, damit sollte das Löschen nun auch bei postgresql korrekt funktionieren.