plotfork und dblog

[justme1968]

beim plot anzeigen wird nicht geschrieben sondern nur gelesen. das sollte also eigentlich auch mit den transaktionen keine probleme machen.

selbst wenn einzelne transaktionen fehl schlagen sollte nicht irgendwann alles zusammenbrechen.

das ist eher ein symptom als die ursache.

gruss
  andre

[betateilchen]

ich werde am Wochenende mal eine mysql DB aufsetzen und nachschauen was da passiert. Bei SQLITE tritt der Fehler nicht auf.

[Tobias]

Das Problem ist ja warscheinlich das die Letzte Transaktion nicht sauber geschlossen wurde. Mal sehen was Udo rausbekommt.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

Nein, das Problem ist, dass das gesamte Verbinungsmanagement in DbLog etwas durcheinander ist.

Zum Zeitpunkt des ersten Logeintrags nach dem plotfork besteht für den Log-Prozess selbst keine gültige Datenbankverbindung mehr.
Das Problem tritt bei SQLITE nicht auf, weil dabei DBI intern ein anderes (einfacheres) Verbindungsmanagement verwendet wird.

Folgender Patch sorgt dafür, dass eine neue Verbindung für den Log-Prozess aufgebaut wird, falls beim Loggen festgestellt wird, dass keine Verbindung mehr besteht.

Code Auswählen Erweitern


Index: 93_DbLog.pm
===================================================================
--- 93_DbLog.pm (Revision 5370)
+++ 93_DbLog.pm (Arbeitskopie)
@@ -388,8 +388,9 @@
################################################################
sub DbLog_Push(@) {
   my ($hash, $DbLogType, $timestamp, $device, $type, $event, $reading, $value, $unit) = @_;
-  my $dbh= $hash->{DBH};
- 
+  my $name = $hash->{NAME};
+  my $dbh  = $hash->{DBH};
+
   # Daten auf maximale laenge beschneiden
   $device   = substr($device,0, $columns{DEVICE});
   $type     = substr($type,0, $columns{TYPE});
@@ -399,8 +400,15 @@
   $unit     = substr($unit,0, $columns{UNIT});

   $dbh->{RaiseError} = 1;
+  $dbh->{PrintError} = 0;
   
-  $dbh->begin_work();
+  eval { $dbh->begin_work() };
+  if ($@) {
+    Log3 ($name, 4, "DbLog $name reconnect due to lost dbh");
+    DbLog_Connect($hash);
+    $dbh  = $hash->{DBH};
+    eval { $dbh->begin_work(); };
+  }
   
   my $sth_ih = $dbh->prepare_cached("INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)") if (lc($DbLogType) =~ m(history) );
   my $sth_ic = $dbh->prepare_cached("INSERT INTO current (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)") if (lc($DbLogType) =~ m(current) );
@@ -433,7 +441,9 @@
   }
   else {
     $dbh->commit();
-    $dbh->{RaiseError} = 0; 
+    $dbh->{RaiseError} = 0;
+    $dbh->{PrintError} = 1;
+ 
   }

   return $dbh->{RaiseError};


Im Anhang die komplette 93_DbLog.pm - es wäre schön, wenn mal ein paar der Betroffenen Leute diese Version testen würden.

[marvin78]

Funktioniert bei mir. Danke.

[betateilchen]

Das Fehlverhalten war übrigens auch die Ursache für meine Problembeschreibung vor einiger Zeit hier:

http://forum.fhem.de/index.php/topic,20345.0.html

Mir war damals nur nicht klar, dass es einen Zusammenhang mit den SVG plots geben könnte.

[justme1968]

eigentlich sollte es doch auch mögich sein eine lösung zu finden die das handle zum loggen gar nicht weiter anfasst.

wo genau geht es denn schief bzw. warum hat es nicht gereicht nach dem fork das original handle nicht zu schliessen sondern in ruhe zu lassen.

gruss
  andre

[betateilchen]

Das habe ich noch nicht endgültig rausgefunden - bitte Geduld, da bin ich noch dran.

Ich wollte aber gestern zumindest eine Lösung für das akute Problem anbieten,
da ich versprochen hatte mich am Wochenende darum zu kümmern.

Davon abgesehen: Man sollte in einem so kritischen Modul wie dem Logging eigentlich wo immer möglich den Fehlerfall mit einplanen und abfangen.
Die bereits im Modul vorhandene Fehlerbehandlung innerhalb der push-Funktion ist zwar schön, aber sie kommt u.U. viel zu spät.

[JoeALLb]

Davon abgesehen: Man sollte in einem so kritischen Modul wie dem Logging eigentlich wo immer möglich den Fehlerfall mit einplanen und abfangen.

Sehe ich auch so
Ich erinnere an den Fehler aus diesem Thread, indem dblog beim start "verschwindet", wenn Mysql zum booten länger benötigt als fhem.
http://forum.fhem.de/index.php/topic,18564.msg123788.html
Vielleicht fällt jemandem für diesen Fall auch noch eine Lösung ein.

[betateilchen]

Vielleicht fällt jemandem für diesen Fall auch noch eine Lösung ein.

das ist relativ einfach, den Fehler kannte ich noch nicht

[marvin78]

Das Problem ist tatsächlich recht nervig. Bei mir kommt es beim Cubieboard II immer mal wieder vor, dass bei einem Neustart des Systems mySQL noch nicht bereit steht (obwohl ich entsprechende Maßnahmen ergriffen habe), wenn FHEM schon eine Verbindung herstellen möchte. Das führt immer dazu, dass das DbLog Device komplett gelöscht wird. Im schlimmsten Fall merkt man das nicht, bis man mal wieder explizit danach sucht. Irgendwo im Forum hat mal jemand geschrieben, dass das ein Feature und kein Bug wäre, ich finde den Beitrag aber gerade auf die Schnelle nicht wieder.

[betateilchen]

kannst Du das nicht einfach im fhem-Startskript lösen?

Code Auswählen Erweitern



# Required-Start:    $remote_fs $syslog



Dort einfach mysql hinzufügen. Das nennt sich dependency based boot sequencing und sorgt dafür, dass ein Dienst erst dann gestartet wird, wenn die in Required-Start eingetragenen Dienste verfügbar sind.

Achtung: die # am Anfang der Zeile ist hier KEIN Kommentarzeichen!

[marvin78]

Naja. Das habe ich gemacht. Hin- und wieder (es ist sehr selten und ich weiß nicht warum) passiert es trotzdem. Ich hatte aber auch noch keine Zeit, mich näher mit den Gründen zu befassen.

Aber selbst wenn man das im Griff hat, sollte es kein normales Verhalten sein, dass das Device mit allen Attributen einfach gelöscht wird, nur weil keine Verbindung hergestellt werden kann.

[Tobias]

kannst Du das nicht einfach im fhem-Startskript lösen?

Code Auswählen Erweitern



# Required-Start:    $remote_fs $syslog



Dort einfach mysql hinzufügen. Das nennt sich dependency based boot sequencing und sorgt dafür, dass ein Dienst erst dann gestartet wird, wenn die in Required-Start eingetragenen Dienste verfügbar sind.

Achtung: die # am Anfang der Zeile ist hier KEIN Kommentarzeichen!

Das habe ich mit meiner PostGreSql-DB damals auch so gemacht... Seitdem nie wieder gelöschte DbLog-Devices...

[betateilchen]

Aber selbst wenn man das im Griff hat, sollte es kein normales Verhalten sein, dass das Device mit allen Attributen einfach gelöscht wird, nur weil keine Verbindung hergestellt werden kann.

ja, aber das ist strategisch. Die Sache mit dem Startskript ist taktisch

Das Device wird übrigens nicht gelöscht, sondern einfach nicht angelegt. Gelöscht wird es erst beim nächsten "save config"

Mit configDB übrigens kein Problem, weil die Versionierung dafür sorgt, dass Du die vorherige Version wiederherstellen kannst, in der auch das DbLog Device noch vorhanden ist.