configDB-Totalverlust nach shutdown restart

Begonnen von Darrol, 18 März 2018, 16:17:56

Vorheriges Thema - Nächstes Thema

Darrol

Hallo allerseits,

den oben besagten Totalverlust meiner Konfiguration konnte ich zwar wiederherstellen, das hier ist also kein Notfall o. ä..

Ich hatte heute das seltsame Erlebnis, dass nach einem "shutdown restart" Befehl die config-Datenbank,augenscheinlich, auf die Fhem-Ursprungskonfiguration zurückgesetzt wurde.
Das hat sich zunächst dadurch bemerkbar gemacht, dass ich in Ermangelung eines Allowed-Devices von der Weboberfläche ausgesperrt war.
Ein Blick in die Logfiles brachte diese Meldungen hier zu Tage:

Zitat2018.03.18 12:02:50 3: [UtilsHourCounter] Init Done with Version 1.0.1.0 - 10.12.2014 (john)
2018.03.18 12:02:50 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_myUtils_movingAve.pm line 15.
2018.03.18 12:02:50 3: telnetPort: port 7072 opened
2018.03.18 12:02:50 3: web: port 8083 opened
2018.03.18 12:02:50 0: Featurelevel: 5.8
2018.03.18 12:02:50 0: Server started with 4 defined entities (fhem.pl:16403/2018-03-13 perl:5.022001 os:linux user:fhem pid:28059)
2018.03.18 12:02:53 1: Connection refused from the non-local address 100.10.1.30:48146, as there is no working allowed instance defined for it

Was mich auf den ersten Blick stutzig gemacht hat war natürlich die Behauptung, dass kein allowed-Device vorhanden sein sollte und auf den zweiten Blick sind mir die 4 Entitäten in Auge gesprungen.
Ein Blick in die DB hat dann bestätigt, dass lediglich das Global-, Web-, Telnet- und ein FileLog-Device definiert waren.

Zu meinem System:
Die Hardware ist ein Intel-NUC und alle für den Betrieb notwendigen Server-Anwendungen sind in Docker-Conteiner separiert.
Mein FHEM läuft in einem Ubuntu 16.04  basierten Container.
Als Datenbank kommt PostgreSQL 9.6.6 zum Einsatz, in meiner FHEM-Datenbank befinden sich sowohl config- als auch die Log-DB.

mit "configDB info" erhalte ich diese Infos:
Zitat
-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
d:$Id: configDB.pm 16235 2018-02-20 21:53:26Z betateilchen $
c:$Id: 98_configdb.pm 16218 2018-02-18 19:23:23Z betateilchen $
-----------------------------------------------------------------
dbconn: Pg:database=fhem;host=*****
dbuser: fhem
dbpass: *****
dbtype: POSTGRESQL
-----------------------------------------------------------------
config: 9792 entries

Ver 0 saved: Sun Mar 18 12:47:27 2018 def: 161 attr: 1234
Ver 1 saved: Fri Mar 16 11:56:28 2018 def: 161 attr: 1232
Ver 2 saved: Wed Mar 14 10:09:23 2018 def: 162 attr: 1238
Ver 3 saved: Mon Mar 12 16:24:45 2018 def: 162 attr: 1238
Ver 4 saved: Wed Feb 28 15:31:39 2018 def: 162 attr: 1237
Ver 5 saved: Fri Feb 16 17:32:53 2018 def: 162 attr: 1237
Ver 6 saved: Fri Feb 16 17:32:30 2018 def: 162 attr: 1237
-----------------------------------------------------------------
state: 3457 entries saved: Sun Mar 18 12:47:27 2018
-----------------------------------------------------------------
filesave: 42 files stored in database
-----------------------------------------------------------------

Ich konnte mein System, wie gesagt, wieder mit einem relativ aktuellen DB-Dump recht zügig wiederherstellen, bin jetzt aber doch relativ verunsichert wie es dazu kam bzw. ahnungslos wie ich der Fehlerursache auf den Grund gehen kann.
Meine Suche hier im Forum hat hierfür auch keine klaren Treffer geliefert.
IntelNUC
-Fhem 5.8 in Ubuntu 16.04-Container
-dbLog & configDB auf Postgres-DB

betateilchen

Zitat von: Darrol am 18 März 2018, 16:17:56
Was mich auf den ersten Blick stutzig gemacht hat war natürlich die Behauptung,

Was Dich viel mehr hätte stutzig machen sollen, ist der Logeintrag, dass Dein FHEM nur mit 4 entities (devices) gestartet wurde  8)

Grundsätzlich glaube ich nicht, dass dieses Phänomen ursächlich etwas mit dem "shutdown restart" zu tun hat. Da muss auf Datenbankebene oder auf Betriebssystemebene irgendwas anderes komplett schiefgelaufen sein. Mein Bauchgefühl sagt mir "Konfigurationsproblem oder - änderung"

Zitat von: Darrol am 18 März 2018, 16:17:56
die config-Datenbank,augenscheinlich, auf die Fhem-Ursprungskonfiguration zurückgesetzt wurde.

Die Datenbank wird unter keinen Umständen auf irgendeine Ursprungskonfiguration zurückgesetzt, das ist im Code der configDB überhaupt nicht implementiert.
Das von Dir beschriebene Verhalten deutet darauf hin, dass zum Startzeitpunkt von FHEM in der Datenbank keine zu configDB gehörenden Tabellen gefunden werden konnten. In diesem Fall werden alle benötigten Tabellen automatisch angelegt und mit einer Minimalkonfiguration gestartet, damit man überhaupt eine Chance hat, sich mit FHEM zu verbinden.

Zitat von: Darrol am 18 März 2018, 16:17:56
bin jetzt aber doch relativ verunsichert wie es dazu kam bzw. ahnungslos wie ich der Fehlerursache auf den Grund gehen kann.

Wie es zu dem Verhalten kam, wirst Du im Nachhinein vermutlich nicht mehr herausfinden können.

Meine Vermutung, wo ich mit der Suche anfangen würde:

Zitat von: Darrol am 18 März 2018, 16:17:56
alle für den Betrieb notwendigen Server-Anwendungen sind in Docker-Conteiner separiert.

Verbindungsprobleme zur Datenbank?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Darrol

Zitat von: betateilchen am 19 März 2018, 12:19:17
Was Dich viel mehr hätte stutzig machen sollen, ist der Logeintrag, dass Dein FHEM nur mit 4 entities (devices) gestartet wurde  8)

Grundsätzlich glaube ich nicht, dass dieses Phänomen ursächlich etwas mit dem "shutdown restart" zu tun hat. Da muss auf Datenbankebene oder auf Betriebssystemebene irgendwas anderes komplett schiefgelaufen sein. Mein Bauchgefühl sagt mir "Konfigurationsproblem oder - änderung"

Die Datenbank wird unter keinen Umständen auf irgendeine Ursprungskonfiguration zurückgesetzt, das ist im Code der configDB überhaupt nicht implementiert.
Das von Dir beschriebene Verhalten deutet darauf hin, dass zum Startzeitpunkt von FHEM in der Datenbank keine zu configDB gehörenden Tabellen gefunden werden konnten. In diesem Fall werden alle benötigten Tabellen automatisch angelegt und mit einer Minimalkonfiguration gestartet, damit man überhaupt eine Chance hat, sich mit FHEM zu verbinden.

...

Verbindungsprobleme zur Datenbank?

Die 4 Entities habe ich im allerersten Moment gar nicht registriert aber ja das sollte einem zu denken geben. :D

Meine letzte Konfig-relevante Aktion war es, wenn ich mich recht erinnere, ein Userattribut zu setzen und zu speichern(Hätte ich vielleicht auch schon erwähnen sollen). Danach kam der restart mit bekanntem Ergebnis.

Das mit den nicht auffindbaren Tabellen hieße ja, dass die Datenbank die Tabellen eigenständig verschlampt hätte. Das wäre für so ein DB-System ein ziemlich übles Problem.
Und wenn die Tabellen vorhanden und von der configDB lediglich nicht gefunden werden dann würde doch der Versuch die selbigen neu zu erstellen lediglich eine Fehlermeldung produzieren oder irre ich mich?
Wie sieht denn das Verhalten von configDB aus wenn es eine vollkommen leergeputzte fhemconfig Tabelle vorfindet? Wird dann auch die besagte Minimalkonfiguration erzeugt?

Verbindungsprobleme zur Datenbank können ja immer in verschiedensten Variationen auftreten.
Zumal ich ja auch nicht das virtuelle Netzwerk der Dockerengine nutze um auf die DB zuzugreifen.(Ich hatte noch keine Zeit und Lust mich mit einer ordentlichen Orchestrierung meiner Container auseinander zu setzen um so das VLAN ordentlich nutzbar zu machen  :-[)
Wie auch immer, für ein kurzeitiges Verbindungsproblem wäre das ein sehr spektakuläres Resultat.


IntelNUC
-Fhem 5.8 in Ubuntu 16.04-Container
-dbLog & configDB auf Postgres-DB

betateilchen

Zitat von: Darrol am 19 März 2018, 20:47:56
Und wenn die Tabellen vorhanden und von der configDB lediglich nicht gefunden werden dann würde doch der Versuch die selbigen neu zu erstellen lediglich eine Fehlermeldung produzieren oder irre ich mich?

Die Tabellen werden mit einem "create table if not exists" angelegt. Das heißt, sie werden tatsächlich nur dann erzeugt, wenn zwar die Datenbank selbst vorhanden ist (ansonsten gäbe es schon beim Verbindungsversuch zur Datenbank einen kompletten Start-Abbruch) aber die Tabellen in der Datenbank nicht vorhanden sind.

Zitat von: Darrol am 19 März 2018, 20:47:56
Wie sieht denn das Verhalten von configDB aus wenn es eine vollkommen leergeputzte fhemconfig Tabelle vorfindet?

Weiß ich nicht - hab ich nie getestet. Aber der Fall kann, von der Code-Logik aus betrachtet, eigentlich nicht vorkommen, weil die fhemconfig nicht der entscheidende Punkt ist und nicht als Erstes gelesen wird.

Da das von Dir beschriebene Verhalten in all der Zeit, die configDB nun existiert, ein einziges Mal aufgetreten ist, schließe ich einen Fehler seitens FHEM mit ziemlicher Sicherheit aus.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Darrol

Zitat von: betateilchen am 19 März 2018, 21:12:46
Da das von Dir beschriebene Verhalten in all der Zeit, die configDB nun existiert, ein einziges Mal aufgetreten ist, schließe ich einen Fehler seitens FHEM mit ziemlicher Sicherheit aus.

Da hast du wohl recht.

Aber immerhin ist es mal hier dokumentiert und evtl. stoße ich ja irgendwann nochmal auf die genau Fehlerursache in meinem Setup.
IntelNUC
-Fhem 5.8 in Ubuntu 16.04-Container
-dbLog & configDB auf Postgres-DB