DBI connect fail

[Hardy74]

Moin,

in anderen Kontexten wurde schon erörtert, dass

Code Auswählen Erweitern

DBI connect('database=fhem;host=hdb-nas.fritz.box;port=3306','raspi22',...) failed: Unknown MySQL server host 'hdb-nas.fritz.box' (-3) at configDB.pm line 751.aufgrund von Netzwerk-/DNS-Problemen zustande kommen kann. Ja, die mag es geben.

Frage: wie kann ich konfigurieren, das fhem nicht den Totalabsturz bei dem Problem hinlegt, sondern einfach nur loggt "habe die db nicht erreicht"?

Momentan verabschiedet sich mit dem Absturz von fhem der ganze Container, den ich nun auf Restart konfiguriert habe. Das funktioniert so weit, aber schöner wäre, wenn fhem nicht so gnadenlos abstürzen würden, nur weil das Netzwerk grad mal unpässlich ist.

Danke!

Grüße,
Hartwig

[betateilchen]

Wohin soll denn gelogged werden, wenn die configDB beim FHEM Start nicht erreichbar ist und deshalb gar kein Filelog device existiert?

Außerdem wäre es mit einem Logging der Nichterreichbarkeit nicht getan. Die configDB muss permanent erreichbar sein, weil daraus regelmäßig gelesen werden muss, beispielsweise, wenn ein SVG plot angezeigt werden soll oder wenn irgendein Modul mit secrets arbeitet, die im FHEM-keystore abgelegt sind.

Das NAS befindet sich doch in Deinem eigenen Netzwerk und hat vermutlich eine feste IP Adresse. Warum gibst Du nicht die IP Adresse als host in der Konfigurationsdatei für die Datenbankverbindung an?
Dann kannst Du zumindest DNS Probleme innerhalb Deines Netzwerkes ausschließen. Ob es tatsächlich hilft, die Nichterreichbarkeiten zu verhindern, musst Du dann beobachten.

[Hardy74]

Wohin soll denn gelogged werden, wenn die configDB beim FHEM Start nicht erreichbar ist und deshalb gar kein Filelog device existiert?

Es ist ja nicht beim Start von fhem, sondern urplötzlich während des laufenden Betriebes. Geloggt werden kann also ganz normal ins lokale fhem log.

Außerdem wäre es mit einem Logging der Nichterreichbarkeit nicht getan. Die configDB muss permanent erreichbar sein, weil daraus regelmäßig gelesen werden muss, beispielsweise, wenn ein SVG plot angezeigt werden soll oder wenn irgendein Modul mit secrets arbeitet, die im FHEM-keystore abgelegt sind.

Es liegt doch in der Natur von Netzwerken, dass diese Hickups haben, kürzere oder längere. Meiner Meinung nach darf ein erwartbares Ereignis, hier der Ausfall des Netzwerkes, nicht dazu führen, dass eine Anwendung ohne Gruß und Kuß abstürzt.

Das NAS befindet sich doch in Deinem eigenen Netzwerk und hat vermutlich eine feste IP Adresse. Warum gibst Du nicht die IP Adresse als host in der Konfigurationsdatei für die Datenbankverbindung an?
Dann kannst Du zumindest DNS Probleme innerhalb Deines Netzwerkes ausschließen. Ob es tatsächlich hilft, die Nichterreichbarkeiten zu verhindern, musst Du dann beobachten.

Das hatte ich tatsächlich auch schon überlegt und werde es auch direkt nach dem Senden dieses Post ändern, und hoffen, dass das ein funktionierender Workaround ist.

[betateilchen]

Es liegt doch in der Natur von Netzwerken, dass diese Hickups haben

Nö. Für mich zumindest nicht.

darf ein erwartbares Ereignis, hier der Ausfall des Netzwerkes

Es fällt doch gar nicht das Netzwerk aus, sondern ein lokaler Dienst im Netzwerk (DNS).

[Hardy74]

Vielleicht ist es nach einem langen Tag einfach schon zu spät, vermutlich zu einfach... aber:

in dblog sehe ich

Code Auswählen Erweitern

DEF
./contrib/dblog/db.conf .*:.*
und ändere genau das File, mache aus hdb-nas.... die ip-adresse, speichern. shutdown restart, container neustart, rapsberry reboot... und nach alle dem steht in dblog hartnäckig:

Code Auswählen Erweitern

dbconn
mysql:database=fhem;host=hdb-nas.fritz.box;port=3306
Wo kommt das her? Auch in der configdb ist in der Spalte P2 kein hdb-nas zu finden.

Bonusfrage, warum liefert

Code Auswählen Erweitern

SELECT * FROM `fhemconfig` where DEVICE = 'logdb'; 135 Zeilen aus 5er Zeilenblöcken, die augenscheinlich identisch sind, sich nur jeweils in der VersionUUID unterscheiden?
Die UUID, die fhem auf der Weboberfläche zeigt, ist spannender Weise nicht dabei, die Abfrage liefert ein leeres Ergebnis. Die UUID steht in der ehemaligen fhem.cfg. fhem wird mit configDb aufgerufen.

[betateilchen]

Vielleicht ist es nach einem langen Tag einfach schon zu spät, vermutlich zu einfach... aber:

in dblog sehe ich

Code Auswählen Erweitern

DEF     
./contrib/dblog/db.conf .*:.*
und ändere genau das File

Tja, vermutlich war es wirklich schon zu spät für Dich.

Wenn Du die Konfiguration für configDB ändern möchtest, dann solltest Du das auch in der richtigen Konfigurationsdatei tun und nicht in der Konfiguration von DbLog.

DbLog und configDB haben nichts miteinander zu tun.

Bonusfrage, warum liefert

Code Auswählen Erweitern

SELECT * FROM `fhemconfig` where DEVICE = 'logdb'; 135 Zeilen aus 5er Zeilenblöcken, die ... sich nur jeweils in der VersionUUID unterscheiden?

Weil Du 135 Versionen Deiner Konfiguration in der configDB gespeichert hast.
Und jede Version hat eine eigene uuid, die Du nirgends in der FHEM Oberfläche finden wirst.