[DBLog] - asynchron - was passiert, wenn FHEM beendet aber DB NA

Begonnen von bartman121, 15 Mai 2023, 20:04:45

Vorheriges Thema - Nächstes Thema

bartman121

Hallo,

ich habe es nicht so recht gefunden, daher frage ich mal ganz frech.

Ich habe einen Raspi an einem entfernten Standort, dieser wählt sich per OpenVPN in meinem eigenen Heimnetz ein. Dummerweise passiert es ab und an mal, dass die OVPN-Verbindung wegbricht und nicht erneut aufgebaut wird. Dazu habe ich ein Script was prüft ob der ovpn-tunnel noch funktioniert (ping auf den ovpn-gateway) und wenn nicht, dann reboote ich den Raspi automatisiert (natürlich prüfe ich nur 3mal am Tag, da der Raspi auch autark ohne OVPN laufen kann).

Ich würde gern Loggen ohne die SD-Karte des Raspi arg zu strapazieren, dafür hätte ich zwei Ideen.

Einerseits könnte ich Log2Ram nutzen? Aber dann kann ich beispielsweise nicht mit Grafana arbeiten, aber die SVG-Geschichte von FHEM wäre auch ausreichend, aber Grafa wäre cooler.

Andererseits könnte ich mit DBLog im async-Modus arbeiten und meinen über vpn erreichbaren mysql-Server nutzen, das wäre meine bevorzugte Lösung.

Ein Wegfall der VPN-Verbindung ist bei DBlog async eher kein Problem, da die Werte nach neuem Verbindungsaufbau wieder geschrieben werden (falls der Cache nicht überläuft). Aber was passiert, wenn die VPN-Verbindung stirbt und ein paar Stunden später rebootet der Raspi (per sudo reboot)? Normalerweise wird ja FHEM geordnet per shutdown herunter (SIGTERM?). Würde DBLog  hier seinen Cache speichern und beim Verbindungsaufbau automatisch wieder importieren?

Weiterhin könnte ich natürlich auf global:SHUTDOWN reagieren und dort den Cache exportieren, würde das funktonieren oder das ist DBLog-Device bei diesem Event bereits "weg"? Dann hätte ich aber noch immer das Problem des Imports später, aber das könnte ich per script automatisieren, falls es öfter passiert.

PS: Bitte nicht hauen, falls die Frage schon öfter kam. Grafana läuft auch im Target-Netzwerk und nicht auf dem Raspi.

Viele Grüße

Andreas

Wernieman

Ich kann Deine Fragen nicht beantworten, mir stellt sich aber eine andere: Muß für den Wiederaufbau OpenVPN wirklich der Pi rebootet werden? Reicht nicht ein Neustart von OpenVPN?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

DS_Starter

Hallo Andreas,

ich würde mal bzgl. DbLog aufkären ...

ZitatAber was passiert, wenn die VPN-Verbindung stirbt und ein paar Stunden später rebootet der Raspi (per sudo reboot)? Normalerweise wird ja FHEM geordnet per shutdown herunter (SIGTERM?). Würde DBLog  hier seinen Cache speichern und beim Verbindungsaufbau automatisch wieder importieren?
In diesem speziellen Fall hat DbLog zunächst keine Chance die Daten wegzuschreiben. Das Modul bzw. der parallele SubProzess würde versuchen die Daten loszuwerden was natürlich nicht gelingt.
Allerdings verzögert DbLog (d.h. eigentlich eine Funktion in fhem.pl) das Herunterfahren von FHEM um eine gewisse maximale Zeit damit bestimmte Dinge abgeschlossen werden können. Diese Zeit kann man mit dem globalen Attr maxShutdownDelay anpassen.

Wenn FHEM gestoppt wird, kommt zunächst der globale Event DELAYEDSHUTDOWN. Auf den könntest du reagieren und mit einem Notify ein:

set <DbLog> exportCache purgecache


ausführen und die Cachedaten in das Filesystem sichern zwecks späterem Import.

global:SHUTDOWN ist definitiv zu spät und würde nicht funktionieren.
Ich habe das beschriebene Verfahren noch nicht ausprobiert. Möglicherweise gibt es Zeit/Abfolgeprobleme die dazu führen dass der Cache bereits an den Subprozess übergeben wurde bevor exportCache über das Notify ausgelöst wird.
Aber das wäre sicherlich noch lösbar.
Du kannst das Verfahren ja mal testen. Wenn ich Zeit finde, probiere ich es auch mal. Klingt ganz interessant.  ;)

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Guten Morgen,

ich habe probiert auf den Event DELAYEDSHUTDOWN zu reagieren und den Export auszulösen.
Prinzipiell reagiert das Notify, allerdings kommt es wie vermutet dazu dass DbLog die Daten bereits an den SubProzess übergeben hat bevor das Notify über den Event getriggert wird. -> Zeit/Abfolgeproblematik.

Aber ich habe eine Idee für eine Lösungsmöglichkeit um per Attribut einen Code/Befehl direkt kurz vor dem Shutdown auführen zu lassen. Dann könnte der User direkt im Modul steuern was er ggf. noch ausgeführt haben möchte.

Wenn dafür Bedarf besteht gebt bitte Bescheid.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

bartman121

erstmal kurz, DANKE Werniemann für den Denkanstoß .... ich muss wirklich nicht rebooten, sondern es reicht den VPN-Client neu zu starten.

@DS_starter
Derzeit besteht kein Bedarf für eine Tiefgreifende Änderung. Ich bin fast der Meinung, dass der Cache nur an den Subprozess übergeben wird, wenn der SQL-Server wirklich connected ist. Hast du provoziert, dass der SQL-Server wirklich weg war?

Ich muss dafür demnächst ein Testszenario aufbauen, aber das schaffe ich zeitlich eher schlecht.

DS_Starter

#5
ZitatIch bin fast der Meinung, dass der Cache nur an den Subprozess übergeben wird, wenn der SQL-Server wirklich connected ist. Hast du provoziert, dass der SQL-Server wirklich weg war?
Das Connection Management zur DB passiert (beim Logging) komplett im SubProzess. D.h. die Übergabe der Daten erfolgt unabhängig vom aktuellen Connect-Status. Allerdings gibt es dann noch einen SubProcess-internen Caching- und Rückgabemechanismus.


ZitatDerzeit besteht kein Bedarf für eine Tiefgreifende Änderung.
Es ist zwar ein bisschen Arbeit, aber als tiefgreifend würde ich das Feature nicht bezeichnen.

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

bartman121

Hallo DS_Starter,

aus meiner Sicht kann ich das Modul so nutzen, wie es derzeit ist.

Es ist aber trotzdem unschön, dass der Cache in einem Subprozess ausgelagert wird unabhängig davon ob die Daten auch weggespeichert werden können. Eine Rückgabe aus dem Subprozess an den Cache des Moduls wäre wünschenswert. Genau dann könnte man über DELAYEDSHUTDOWN mein Szenario (was vermutlich nichtmal sehr ungewöhnlich ist). Immer dann wann DB-Server und Raspi physisch getrennt sind, dann kann es durch Beteiligung anderer Geräte (Netzwerk oder wie bei mir VPN) zu einem Abbruch der Verbindung kommen.

Falls Dir mal langweilig ist, dann kannst du dafür ja mal etwas basteln, aber extrem wichtig ist es nicht. Auch der automatische Import des gespeicherten Caches muss nicht zwingend gemacht werden. Man muss natürlich auch bedenken, dass es auch Nutzer gibt die irgendwann mal DBLog eingestellt haben und später den DB-Server einstampfen ohne das DBLog-Device zu löschen. Als Ergebnis würde bei meiner gewünschten Änderung irgendwann ein riesiger Batzen an gespeicherten Caches entstehen.


DS_Starter

ZitatEine Rückgabe aus dem Subprozess an den Cache des Moduls wäre wünschenswert.
Das passiert auch. Hatte ich ja geschrieben -> ...  Allerdings gibt es dann noch einen SubProcess-internen Caching- und Rückgabemechanismus.

Dennoch werden im Fall von DELAYEDSHUTDOWN alle Daten an den SP übergeben um final alles wegzuschreiben.
Im Normalfall ist die DB auch verfügbar.
Einen automatische Import des gespeicherten Caches würde ich ohnehin nicht implementieren. Dafür gibt es den manuellen Prozess "set ... importCachefile".
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Wernieman

Zitat von: bartman121 am 16 Mai 2023, 09:34:23.... ich muss wirklich nicht rebooten, sondern es reicht den VPN-Client neu zu starten.

Ich kenne jetzt OpenVPN zu wenig, aber gibt es nicht auch eine reconnect-Anweisung? Bin immer Vorsichtig, gleich die Große Keule (Pi reboot, Deamon reboot etc.) rauzuholen ..
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

DS_Starter

In meinem contrib liegt eine Version zum Testen.
Wird FHEM gestoppt und der "last write Cycle" schlägt fehl weil die Verbindung zur DB nicht aufgebaut werden kann, werden die Daten in ein cache-File geschrieben.

Im Log ist dann zu sehen:

2023.05.16 22:47:58.896 2: DbLog LogDB1 - ERROR: DBI connect('database=fhemtest1;host=192.168.2.44;port=3306','fhemtest1',...) failed: Access denied for user 'fhemtest1'@'fhemtest.myds.me' (using password: YES) at ./FHEM/93_DbLog.pm line 2557.
2023.05.16 22:47:59.232 2: DbLog LogDB1 - no connection to the database possible in the last database write cycle, export to file instead...
2023.05.16 22:47:59.253 3: DbLog LogDB1 - 129 Cache rows exported to ./log/cache_LogDB1_2023-05-16_22-47-59
2023.05.16 22:47:59.262 3: DbLog LogDB1 - Cache purged after exporting rows to ./log/cache_LogDB1_2023-05-16_22-47-59.
2023.05.16 22:47:59.272 2: DbLog LogDB1 - Last database write cycle done

Könnt ihr gern mal ausprobieren.

Zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:

"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

bartman121

Hallo DS_Starter,

danke schonmal. Ich komme erst am Wochenende dazu das zu testen, ich werde dazu Sonntag sicher eine Rückmeldung geben können.

Werniemann, ja es gibt eine Anweisung die genau das macht. keepalive 10 120 in der client.conf. Damit wird alle 10Sekunden per Ping geschaut ob der der VPN-Server noch "online" ist. Wenn das 120Sekunden negativ ist, dann wird reconnected.

Danke euch beiden

Andreas

DS_Starter

Hast du mal getestet ?
Ich habe bei mir die Lösung eingehend geprüft und würde sie einchecken.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

bartman121

#12
Hallo,

sorry, ich hatte es verpeilt. Aber weil ich so froh bin, dass du das gebaut hast, habe ich es jetzt mal getestet. Ich bin mir nur nicht ganz sicher ob mein Szenario den Fehlerfall wirklich abbildet, aber dazu kannst du etwas sagen.

Also, ich habe die Zugangsdaten des DBlog-users am MySQL-Server geändert, dadurch kann natürlich nicht mehr in die DB geschrieben werden.

Der Cache hat sich entsprechend gefüllt.

über dieses Notify habe ich auf das Event DELAYEDSHUTDOWN getriggert:
defmod n_global_delayed_shutdown notify global:DELAYEDSHUTDOWN { fhem("set LOG2SQL exportCache purgecache");;}bitte nicht hauen, falls der Perl-Code dort unnötig ist, oder die Semikolon eigentlich nicht verdoppelt werden müssen, es geht aber so!

Der Cache wurde ins Logverzeichnis geschrieben:
1. shutdown über die fhem-Kommandozeile
2. service fhem stop
3. reboot

Ist dieses Szenario vergleichbar mit einem nicht erreichbaren SQL-Server? Oder muss ich wirklich im laufenden Betrieb den SQL-Server stoppen und damit mein Hauptfhem kurz stören (weil configDB)?

Wenn das Szenario vergleichbar ist, dann kann ich die Funktionalität bestätigen.

Ich kann am externen Standort das VPN nicht einfach beenden, weil ich eben dann auch den Zugriff auf den Raspi verlieren würde :D

Grüße

Andreas

DS_Starter

#13
Zitatüber dieses Notify habe ich auf das Event DELAYEDSHUTDOWN getriggert:

Ah, sorry. Ich hatte es nicht in der Deutlichkeit geschrieben.
Als User muß man garnichts tun oder definieren.
Sobald ein (regulärer) Shutdown kommt (ein Crash wird nicht abgefangen) und der "letzte Schreibzyklus" fehlschlägt weil DB nicht zugreifbar oder der User falsch etc., werden die Daten an den Hauptprozess zurück gegeben und anschließend in ein File geschrieben.
Erst danach wird der Shutdown freigegeben.

Natürlich kann es sein dass ein zu gering eingestelltes globales Attr maxShutdownDelay vorher greift und FHEM runter reißt. Alles kann man nicht abfangen, da muß der User auch mal ein Szenario durchtesten wenn es ihm wichtig ist.

Aber, wie gesagt, die Vorraussetzungen um eine solche Problematik zu handhaben wären damit gegeben.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter