[gelöst] Fehler beim fhem-start configDB

[oldscout]

mysql, seit 3 Jahren...

[betateilchen]

Mit mysql funktioniert die Migration und die Prüfung auf die anschließende Tabellenexistenz problemlos.
Das ist mehrfach getestet und in der aktuellen FHEM Statistik sind alleine 30 FHEM Installationen verzeichnet, die mysql mit b64 benutzen.

Die Fehlerursache vermute ich nach wie vor in Deiner Datenbankinstallation.

[oldscout]

ok, Datenbankfehler... Tabelle da, fhem startet, Tabelle weg, fhem startet nicht mit genannten Fehler.
an welcher Stelle kann ich da noch schauen, die Konvertierung ist durchgelaufen, fhemb64filesave existiert, solange fhem nicht neugestartet wird,z.b. nach Update geht es super.
Bis zur Konvertierung lief es auch. Wo also könnte der Fehler liegen?
Gibt es ev. Probleme hinsichtlich der Versionen perl/Mysql??
Meine Notlösung wird sein, dass ich den Block der Konvertierung auskommentiere/lösche bzw. das drop rausnehme, Konvertierung ist ja durch....wozu also jedesmal testen.
Keine schöne Lösung, aber eine.
Trotzdem würde ich mich noch über ein paar Hinweise freuen.
danke.

[betateilchen]

Trotzdem würde ich mich noch über ein paar Hinweise freuen.

ich habe keine, sonst würde ich sie Dir ja geben.

[AitschPi]

Moin moin,

offensichtlich ist oldscout nicht allein - ich habe seit der Umstellung auch das Problem:

Bei mir läuft fhem auf einem Raspberry 2, die Konigurationsdaten und Logs werden in der externen MySQL-Datenbank auf meinem NAS von QNAP im LAN gespeichert. Konkret läuft da MariaDB 5.5.51.


Der Fehler ist replizierbar:

• Fhem ist nicht aktiv. Aus einer alten Installation füge ich die alte korrekte Tabelle fhembinfilesave ein. Die Tabelle fhemb64filesave existiert nicht.
• Nach dem Start von fhem wird fhembinfilesave in fhemb64filesave konvertiert und fhembinfilesave gelöscht.
• fhem arbeitet problemlos.
• Fhem kann fehlerfrei beendet werden (shutdown oder über init-Skript)
• Fhem kann nicht mehr gestartet werden. Ursache ist die fehlende Tabelle fhembinfilesave - dass fhemb64filesave existiert, spielt keine Rolle.
• Ab hier kann ich nur noch die alte Tabelle fhembinfilesave aus dem backup wiederherstellen und die fhemb64filesave löschen, erst dann lässt sich fhem wieder starten - dann beginnt alles bei Ziffer 1.

Woran kann das liegen??? Offensichtlich scheint das ja bei den meisten fehlerfrei zu funktionieren. Betateilchen, welche Daten brauchst Du noch zur Fehleranalyse bzw. was kann ich hier vor Ort tun, um den Fehler zu vermeiden?

[oldscout]

Hallo wieder,
ich bin doch nicht allein.......
Der Test, ob die Tabelle fhembinfilesave existiert gibt bie mir immer das Array zurück... egal ob die Tabelle da ist oder nicht.
Hat sich die ganze DB irgendwie zerlegt? fhem läuft aber wie gewohnt... mysqlcheck gibt ein ok in allen Tabellen zurück.
an AitschPi: kommentiere das drop in configDB.pm aus und fhem startet erstmal. Ich habe einfach eine leere Tabelle fhembinfilesave erstellt.
Ich habe noch mysql 5.5.
Prüfe ich hingegen auf "irgendeine" noch nie existierende Tabelle in der DB, dann wird der Array-Zeiger als undefiniert zurückgegeben.

[oldscout]

an CoolTux: wieviel Popcorn gab es schon?

[CoolTux]

an CoolTux: wieviel Popcorn gab es schon?

Hier im Forum über die Jahre. Eine Menge, glaube mir. Deswegen sind Udo und ich ja auch so "smart"   

[AitschPi]

Ah, jetzt weiß ich, woher "smart home" kommt... ;o)

[betateilchen]

Wenn die Prüfung auf die nicht mehr vorhandene Tabelle immer noch ein "true" zurückliefert, handelt es sich entweder um ein Problem der Datenbank selbst (Cache?) oder der perl Datenbanktreiber hat eine Macke.

Die Sache mit dem Cache ließe sich leicht prüfen: Nach der Migration den mysql Server einmal durchstarten.

Muss mal überlegen, ob ich die Prüfung anders umsetzen kann. Für mich ist das Problem, dass keine meiner mysql Installationen dieses Verhalten zeigt, das macht das Testen schwierig.



Könnte jemand von den "Betroffenen" bitte folgendes testen:

1. In der Konfigurationsdatei configDB.conf den parameter b64 mit 1 übergeben

Code Auswählen Erweitern


%dbconfig= (
connection => "connectionString",
user => "user",
password => "password",
b64 => "1",
);


2. dann mit der hier angehängten Moduldatei testen


edit: die Datei befindet sich jetzt in SVN und kommt ab 24.08. automatisch per update

[AitschPi]

Läuft. ;o)

Was könnte ich für Dich "ferntesten"? Ursache könnte ja (bei mir) die externen Datenbanken (1x config, 1x log, gleiche Zugangsdaten), die mariaDB-mySQL-Version auf QNAP oder ein fehlerhaftes Modul in fhem selbst sein... So viele Möglichkeiten. Oder einfach so lassen, läuft ja jetzt?

[betateilchen]

Danke für die Rückmeldung, hatte die Änderung heute morgen einfach mal so während der Bahnfahrt ins Büro ausgedacht und eingebaut.

Was könnte ich für Dich "ferntesten"?

Brauchst Du nicht, danke. Die Prüfung für den Migrationsmechanismus werde ich entsprechend umbauen und eine datenbankunabhängige Variante verwenden. Vermutlich werde ich die Konfigurationsdatei nach der Migration automatisch um den Parameter b64 erweitern und dann diesen Parameter prüfen. Das muss ich aber in Ruhe machen.

Wichtig ist, dass wir erstmal einen Workaround haben, falls noch mehr Fälle mit diesem Problem auftauchen.

Irgendwann fliegt die Migration ohnehin wieder aus der Moduldatei, aber das wird frühestens in einigen Monaten passieren (Kompatibilitätsgründe)

[AitschPi]

Danke. Und gut, dass Du mit der Bahn und nicht mit dem Auto fährst... ;o)


Gesendet von iPhone mit Tapatalk Pro

[betateilchen]

Eine BahnCard100 hat man nicht ohne Grund...

[oldscout]

Bei mir läuft es auch jetzt.  danke.