Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[Thowe]

Hallo Heiko,
noch gewinne ich mit der Hash-gesteuerten Ausführung an Übersichtlichkeit und damit Wartbarkeit. Der Wettbewerb zwischen fhem.cfg und 99_myUtils.pm hat wieder mehr Gewicht auf die Konfigurationsseite gebracht. Vielen Dank und
viele Grüße,
Thowe

[betateilchen]

Ich würde solche "Romane" niemals in ein Attribut schreiben.
Nicht alles, was technisch möglich ist, ist automatisch auch sinnvoll.

[Thowe]

Hallo betateilchen,

Ich würde solche "Romane" niemals in ein Attribut schreiben.
Nicht alles, was technisch möglich ist, ist automatisch auch sinnvoll.

ist zu pauschal gehalten. Auf welches Attribut bezieht sich Deine Aussage? Was wäre die sinnvolle Alternative?
VG Thowe

[betateilchen]

Sorry, Attribut war falsch, der Roman steht ja im DEF eines at.
Aber auch da würde ich sowas nicht hinschreiben.
Sowas ist in der 99_myUtils.pm einfach besser aufgehoben und leichter wartbar.

[dennisk]

Guten Morgen zusammen,

ich nutze DbRep noch nicht sehr intensiv, aber seit ich es instantiiert habe, habe ich im Log, auch über viele Updates hinweg, sporadisch diese Fehlermeldungen:

Code Auswählen Erweitern

2024.03.19 17:39:39 1: PERL WARNING: readdir() attempted on invalid dirhandle DIR at /usr/share/fhem/FHEM/93_DbRep.pm line 552.
2024.03.19 17:39:39 1: PERL WARNING: closedir() attempted on invalid dirhandle DIR at /usr/share/fhem/FHEM/93_DbRep.pm line 557.

Der betreffende Code scheint immer dieser hier zu sein, nach einem Update von DbRep dann mit mglw. anderen Zeilennummern:

Code Auswählen Erweitern

  while (my $file = readdir(DIR)) {
      next unless (-f "$dir/$file");
      next unless ($file =~ /^$sd/);
      push @bkps,$file;
  }
  closedir(DIR);

Fehlt mir hier irgendein Attribut, oder habe ich etwas falsch konfiguriert?

Hier mal mein DEF des DbRep Gerätes:

Code Auswählen Erweitern

defmod globalDbLog_DbRep DbRep globalDbLog
attr globalDbLog_DbRep dumpDirLocal /var/lib/fhem/dblog/

setstate globalDbLog_DbRep initialized
setstate globalDbLog_DbRep 2024-03-15 17:45:47 state initialized

Das Verzeichnis dumpDirLocal ist les- und schreibbar durch den User, unter dem fhem läuft. Oder hat es mit dumpDirLocal gar nichts zu tun? Hat jemand eine Idee, was die Warnung auslösen und wie ich das beheben könnte?

Vielen Dank schon mal!

[betateilchen]

Vermutlich kommt die Meldung im Log immer dann, wenn Du das DbRep device im Frontend anzeigen lässt?

Meines Erachtens wäre es sinnvoll, im opendir() ein paar Zeilen vorher eine Fehlerbehandlung einzubauen, damit DbRep_Set() erst gar nicht bis zu der Stelle kommt, an der ein Zugriff erfolgt.

Aber warum die Fehlermeldung verursacht wird, ist damit noch nicht klar.

Das Verzeichnis dumpDirLocal ist les- und schreibbar durch den User, unter dem fhem läuft.

Ohne Dir zu nahe treten zu wollen: sowas haben schon viele behauptet

Nimm doch mal testweise das Attribut komplett raus, dann wird das Standardverzeichnis verwendet, auf das FHEM sicher Zugriff hat.

[dennisk]

Vermutlich kommt die Meldung im Log immer dann, wenn Du das DbRep device im Frontend anzeigen lässt?

Das könnte in der Tat sein, ist aber schwer nachzuvollziehen, da das Ganze nur sehr sporadisch auftaucht. Aber ich werde versuchen, darauf zu achten.

Meines Erachtens wäre es sinnvoll, im opendir() ein paar Zeilen vorher eine Fehlerbehandlung einzubauen, damit DbRep_Set() erst gar nicht bis zu der Stelle kommt, an der ein Zugriff erfolgt.

Aber warum die Fehlermeldung verursacht wird, ist damit noch nicht klar.

Hast Du da eine konkrete Idee, was ich wo einbauen sollte?

Das Verzeichnis dumpDirLocal ist les- und schreibbar durch den User, unter dem fhem läuft.

Ohne Dir zu nahe treten zu wollen: sowas haben schon viele behauptet

Nimm doch mal testweise das Attribut komplett raus, dann wird das Standardverzeichnis verwendet, auf das FHEM sicher Zugriff hat.

Das Attribut hatte ich ursprünglich mal gesetzt, weil der Fehler schon ohne das Attribut auftrat. Ich habe soeben aber in fhem als Kommando folgendes eingegeben und ausgeführt: {qx(echo "test" > /var/lib/fhem/dblog/testfile)}
Die vorher nicht existente Datei wurde im Verzeichnis erfolgreich angelegt und der String auch erfolgreich in die Datei geschrieben. Dann sollte doch auch DbRep schreiben können, oder?

Vielen Dank in jedem Fall für Deinen Input

[DS_Starter]

Es werden bestimmte Files im Verzeichnis "$attr{global}{modpath}/log/" gesucht.
D.h. du müsstest überprüfen was bei dir im global Device Attr "modpath" steht (üblicherweise '.') und ob es dieses Verzeichnis bei dir gibt (was Standard wäre).

[dennisk]

Es werden bestimmte Files im Verzeichnis "$attr{global}{modpath}/log/" gesucht.
D.h. du müsstest überprüfen was bei dir im global Device Attr "modpath" steht (üblicherweise '.') und ob es dieses Verzeichnis bei dir gibt (was Standard wäre).

Vielen Dank für den Hinweis. Bei mir steht in

Code Auswählen Erweitern

$attr{global}{modpath} /usr/share/fhem Ist eine Installation, die ich damals über das Paket fhem aus dem Arch User Repository unter Arch Linux installiert habe, siehe auch https://wiki.archlinux.org/title/FHEM Und in diesem Verzeichnis existierte kein Verzeichnis

Code Auswählen Erweitern

log Dieses habe ich jetzt mal hinzugefügt. Reicht das schon? Oder such DbRep etwas bestimmtes darunter?

[DS_Starter]

Dieses habe ich jetzt mal hinzugefügt. Reicht das schon? Oder such DbRep etwas bestimmtes darunter?

Das reicht.
Ist dumpDirLocal nicht gesetzt, werden Dump-Files mit "dumpMySQL clientSide" oder "dumpSQLite" in dieses Verzeichnis per default abgelegt bzw. wird aus (evtl.) gefundenen Files in dem Verzeichnis eine Drop-Down Liste für die Restore Set-Befehle erstellt.
Die Hilfe zum Attr dumpDirLocal  erklärt den Zusammenhang ebenfalls.

[dennisk]

Dieses habe ich jetzt mal hinzugefügt. Reicht das schon? Oder such DbRep etwas bestimmtes darunter?

Das reicht.
Ist dumpDirLocal nicht gesetzt, werden Dump-Files mit "dumpMySQL clientSide" oder "dumpSQLite" in dieses Verzeichnis per default abgelegt bzw. wird aus (evtl.) gefundenen Files in dem Verzeichnis eine Drop-Down Liste für die Restore Set-Befehle erstellt.
Die Hilfe zum Attr dumpDirLocal  erklärt den Zusammenhang ebenfalls.

Danke. Aber dumpDirLocal ist doch gesetzt. Siehe das DEF in meinem Post weiter oben.

[DS_Starter]

Aber dumpDirLocal ist doch gesetzt.

Wenn es gesetzt ist, wird das angegebene Verzeichnis benutzt.
Wenn die Fehlerausschrift in diesem Fall auftritt, kann das angegebene Verzeichnis nicht gelesen werden.

[flummy1978]

Tagchen,

ich versuche immernoch den o.g. Fehler hinterher zu kommen:

Code Auswählen Erweitern

2024.03.22 14:38:20.511 2: DbRep SQL_DBrep_Device - ERROR - DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at ./FHEM/93_DbRep.pm line 11994Dieser kommt seit der Umstellung 10-30 mal pro Tag von einem der Device das aktuell alle 15 Min ausgeführt wird.

Die betreffende Zeile 11994 ist mit

#    führt ein sth execute prepared Insert aus
#    return ERROR oder die Anzahl der betroffenen Zeilen

kommentiert. Leider kann ich mit dem Hinweis so erstmal nichts anfangen.... Kannst Du mir einen Tipp geben, woher das kommt, wodurch diese Fehlermeldung kommt? Eigentlich sollte die DB (bzw das DBRep) weniger zu tun haben, als früher, weil alles der Reihe nach erfüllt wird und nicht teilweise 4 Aufrufe für ein Device nötig sind.....

@flummy1978,
Nach kurzer Überlegung halte ich es für angebracht die aus den execafter/before resultierenden Meldungen auf verbose 3 setze. So essntiell sind sie im Normalfall nicht und du kannst das DbRep mit verbose 2 betreiben ohne wichtige Meldungen zu verpassen.

Wenn ich es richtig verstanden habe, hast Du das bereits in der aktuellen Ausführung umgestellt? Ich bekomme noch die Meldung:

Code Auswählen Erweitern

2024.03.22 18:52:30.481 2: DBLogging - Connection closed until 19:52:30 (3600 seconds).
Die allerdings erst sichtbar geworden ist, nachdem ich das entsprechende DBRep Device auf verbose 2 umgestellt habe.

VG
Andreas

[DS_Starter]

Hallo Andreas,

Wenn ich es richtig verstanden habe, hast Du das bereits in der aktuellen Ausführung umgestellt? Ich bekomme noch die Meldung:

Diese Meldung kommt aber nicht aus DbRep, sondern DbLog als Reaktion auf das Schließen der Verbindung.

Die Datenbank Meldung:

DBD::mysql::st execute failed: Lock wait timeout exceeded

Ist im Prinzip kein technischer Fehler im eigentlichen Sinn, sondern ist eine Reaktion darauf dass
die Situation "Lock wait timeout exceeded" auftritt, wenn eine Transaktion auf eine Sperre wartet, die von einer anderen erworben wurde.

Du könntest den Server Parameter innodb_lock_wait_timeout versuchen zu trimmen.
Eine weitere Möglichkeit wäre im DbLog das Attr commitMode = basic_ta:off setzen.

Möglicherweise arbeitet deine Datenbank sehr langsam. Das erkennst du evtl. mit den DbLog Attr showproctime = 1.

EDIT: Im DbRep sqlCmd kannst du den Befehl "SHOW ENGINE INNODB STATUS;" ausführen. Es zeigt ein Ergebnis welches u.U. hilfreich sein kann den Verursacher des Lock wait zu finden.

Grüße,
Heiko

[DS_Starter]

@Thowe,
bist du mit der aktuellen Testversion von DbRep soweit zufrieden dass du deine Cases umsetzen kannst?
Wenn es soweit passt, würde ich die V auch mal einchecken.

Grüße,
Heiko