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.

[Hardy74]

DbLog und configDB haben nichts miteinander zu tun.

Das ist mir klar, da aber beide auf dieselbe DB zugreifen, ist einer der beiden "Schuld" an den fhem Abstürzen.

Auf der Oberfläche zeigt logDB nach wie vor den Namen des NAS, obwohl ich die config auf die IP geändert habe.

Die Config von von configDB enthält ebenfalls die IP Adresse.

Seit Mitternacht hat fhem bereits 6x die Grätsche gemacht, mit eben dem DBI Fehler, nun statt des Namens eben mit der IP von meinem NAS. Insofern ist es augenscheinlich mit der IP schlimmer geworden als mit dem Namen.

Meine initiale Frage bleibt: wie bekommt man es hin, dass fhem nicht ohne Gruß und Kuß gnadenlos abschmiert, sondern lediglich ins fhem.log schreibt (was es ja tut), dass da auf die Datenbank nicht zugegriffen werden konnte und weiter läuft.

[betateilchen]

DbLog und configDB haben nichts miteinander zu tun.

Das ist mir klar, da aber beide auf dieselbe DB zugreifen,

das sollte man so nicht tun...

Auf der Oberfläche zeigt logDB nach wie vor den Namen des NAS, obwohl ich die config auf die IP geändert habe.

Du weißt aber schon, dass die Konfigurationsdatei für DbLog in der configDB liegt, wenn man mit configDB arbeitet? Da stellt sich die Frage, ob Du die Konfigurationsdatei, die Du im Dateisystem bearbeitet hast, danach erneut in die Datenbank importiert hast.

mit der IP von meinem NAS. Insofern ist es augenscheinlich mit der IP schlimmer geworden als mit dem Namen.

Das kann mit IP eigentlich nicht schlimmer werden.

Meine initiale Frage bleibt: wie bekommt man es hin, dass fhem nicht ohne Gruß und Kuß gnadenlos abschmiert,

Das bekommst Du nicht hin.

[Hardy74]

das sollte man so nicht tun...

Warum? Las uns zunächst das Wording klären. Ein Datenbankserver, z.b. MariaDB besteht aus mehreren Datenbanken, z.b. fhem, weewx, ..., jede Datenbank besteht aus mehreren Tabellen, z.b. fhemconfig, history, ....

Was genau sollte man nicht tun und warum? logdb und configdb tatsächlich nicht in derselben Datenbank, z.b. fhem, vorhalten? Lokal würden sie das doch auch tun!?

Du weißt aber schon, dass die Konfigurationsdatei für DbLog in der configDB liegt, wenn man mit configDB arbeitet?

Ja. Auch hier gibt es in der configDB mehrere identische Einträge für das Device logdb. Bis auf die UUID identisch, in der define Zeile ist unter P2 der Pfad zum config file hinterlegt. Annahme ist, dass also ein geändertes Configfile von dem Pfad beim nächsten Start gelesen wird und die Änderungen wirksam sind.

Ich werde auch die Änderung auf die IP wieder Rückgängig machen und den Namen eintragen. Seit der Änderung auf die IP fällt fhem nur noch auf die Nase.

Das bekommst Du nicht hin.

Warum nicht? In dem Augenblick, wo die DBI Zeile ins Log geschrieben wird, lebt fhem doch noch!? Ich habe von Perl keine Ahnung, bin dafür allerdings seit über 20Jahren in der C++ Entwicklung. Irgendjemand sprach mal davon, dass sich in dem "DBI Fehlerfall" Dinge "verhakelt" hätten.. das meint was? Probleme beim Multithreading, verklemmte Semaphoren, oder wie evtl. Pendants bei Perl heißen mögen? Oder was ist die Ursache, dass man als Entwickler die Anwendung sehenden Auges abstürzen läßt?

Offenbar gibt es aber auch Seiteneffekte, die ich noch verstehen muss: heute, wo die Probleme mit dem fhem-Container so massiv sind, war auch der weewx Container beleidigt. Was haben die beiden gemeinsam? Sie laufen auf demselben Raspberry und sie benutzen beide den MariaDB Server auf dem NAS aber natürlich unterschiedliche Datenbanken. Logs konnte ich mir noch nicht anschauen, ein Reboot des Raspberrys hat hier aber erstmal für Abhilfe gesorgt.

[betateilchen]

Was genau sollte man nicht tun und warum? logdb und configdb tatsächlich nicht in derselben Datenbank, z.b. fhem, vorhalten? Lokal würden sie das doch auch tun!?

Man sollte auch in einem lokal laufenden Datenbankserver die beiden Anwendungen "DbLog" und "configDB" besser in getrennten Datenbanken halten.

Auch hier gibt es in der configDB mehrere identische Einträge für das Device logdb. Bis auf die UUID identisch

Du bist komplett an der falschen Stelle unterwegs. Die Konfigurationsdatei liegt in der configDB an einer ganz anderen Stelle. In der "fhemconfig" steht im define nur der Verweis, wie die zu verwendende Datei benannt ist.
Mit einer Pfadangabe hat das nichts mehr zu tun.

Seit der Änderung auf die IP fällt fhem nur noch auf die Nase.

Du scheinst ein ganz anderes Problem in Deinem Netzwerk zu haben.

Das bekommst Du nicht hin.

Warum nicht?

Die Betonung lag hier auf dem "Du". Denn Du bist nicht der Entwickler von configDB und ich habe nicht vor, an dem Verhalten etwas zu ändern. Bring Dein Netzwerk in Ordnung, dann wird es auch keine Abbrüche mehr geben.

Eine Kopfschmerztablette beseitigt ja in aller Regel auch nicht die Ursache der Schmerzen.

bin dafür allerdings seit über 20Jahren in der C++ Entwicklung

20 Jahre? Oh, ein Anfänger

Oder was ist die Ursache, dass man als Entwickler die Anwendung sehenden Auges abstürzen läßt?

Die Ursache ist, dass ich als Entwickler vor langer Zeit entschieden habe, dass ich genau dieses Verhalten haben möchte, um den Anwender dazu zu bringen, seine Installation und seine Netzwerkumgebung in Ordnung zu bringen und zu halten.

Es macht keinen Sinn, FHEM weiterlaufen zu lassen, wenn die configDB nicht verfügbar ist. Dafür wird sie tatsächlich zu oft gebraucht.

[Hardy74]

Man sollte auch in einem lokal laufenden Datenbankserver die beiden Anwendungen "DbLog" und "configDB" besser in getrennten Datenbanken halten.

Alles klar, dann werde ich das mal trennen. Wahrscheinlich steht das auch irgendwo!? 

Die Betonung lag hier auf dem "Du".

Die Ursache ist, dass ich als Entwickler vor langer Zeit entschieden habe, dass ich genau dieses Verhalten haben möchte, um den Anwender dazu zu bringen, seine Installation und seine Netzwerkumgebung in Ordnung zu bringen und zu halten.

Es macht keinen Sinn, FHEM weiterlaufen zu lassen, wenn die configDB nicht verfügbar ist. Dafür wird sie tatsächlich zu oft gebraucht.

Valide Begründung!

Bei 2 der momentan 7 Abtürze heut war noch ein bisschen Kontext:

Code Auswählen Erweitern

DBI connect('database=fhem;host=192.168.178.252;port=3306','raspi22',...) failed: Lost connection to MySQL server at 'reading authorization packet', system error: 104 at configDB.pm line 751.


Bring Dein Netzwerk in Ordnung, dann wird es auch keine Abbrüche mehr geben.

Ich werde berichten... 

[betateilchen]

Bei 2 der momentan 7 Abtürze heut war noch ein bisschen Kontext:

Code Auswählen Erweitern

DBI connect('database=fhem;host=192.168.178.252;port=3306','raspi22',...) failed: Lost connection to MySQL server at 'reading authorization packet', system error: 104 at configDB.pm line 751.


Wenn Du nach

Code Auswählen Erweitern

Lost connection to MySQL server at 'reading authorization packet'
googelst, wirst Du jede Menge Informationen finden. Das Problem scheint also tatsächlich Deine Systemumgebung zu sein und nicht FHEM.