DBlog Error - mit MySQL und Plotfork stürzt FHEM ab

[chris1284]

ich hatte plotfork auf 1 gesetzt weil mir die plots zu langsam kamen.
nun crashed fhem wenn ich einen plot anklicke. meldung in der konsole:

DBD::mysql::st execute failed: MySQL server has gone away at ./FHEM/93_DbLog.pm line 1494.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 135.

lösche ich plotfork geht wieder alles. fhem ist aktuell. wer verursacht hier den fehler, dblog oder Blocking.pm?

[franky08]

Hallo, DbLog läuft nicht mit plotfork! Das ist auch schon seit ewig bekannt aber bis jetzt nie überarbeitet worden. Schade, ich nutze seit einem Jahr DbLog mit sqlite und würde auch gerne plotfork nutzen.

z.B. hier: http://forum.fhem.de/index.php/topic,21087.msg146063.html#msg146063

Bei mir crashed fhem zwar nicht aber die DB kann nicht mehr connectet werden

VG
Frank

[justme1968]

plotfork läuft sehr wohl mit sqlite. ich verwende es auf drei systemen.

mit MySQL gibt es aber scheinbar noch/wieder probleme.

betateilchen hatte das zwischenzeitlich auch schon mal repariert.

gruß
  andre

[franky08]

Hallo Andre, bei mir gibt es mit plotfork kein DB connect mehr.

Hab gerade mal in den Log gesehen, es wird zwar zur DB verbunden aber es können keine Daten in die DB geschrieben werden.

Code Auswählen Erweitern

2015.02.17 21:00:00 3: CUL_HM set WZ_rechts_Heizung_Clima controlManu 24.5
2015.02.17 21:00:41 3: Connecting to database SQLite:dbname=/opt/fhem/fhem.db with user
2015.02.17 21:00:41 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established for pid 1049
2015.02.17 21:00:41 3: Connecting to database SQLite:dbname=/opt/fhem/fhem.db with user
2015.02.17 21:00:41 2: DbLog: Failed to insert new readings into database: DBD::SQLite::st execute failed: attempt to execute on inactive database handle at ./FHEM/93_DbLog.pm line 447.

2015.02.17 21:00:41 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established for pid 1048
2015.02.17 21:00:42 3: Connecting to database SQLite:dbname=/opt/fhem/fhem.db with user
2015.02.17 21:00:42 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established for pid 1050
2015.02.17 21:00:42 2: DbLog: Failed to insert new readings into database: DBD::SQLite::st execute failed: attempt to execute on inactive database handle at ./FHEM/93_DbLog.pm line 447.


VG
Frank

[marvin78]

Getestet und ich kann das Verhalten bei MySQL wieder bestätigen. Es werden zwar Verbindungen für die Plots aufgebaut, aber nachdem man zum ersten mal einen Raum mit Plots besucht hat, ist die Hauptverbindung beendet und verbindet sich auch nicht von allein wieder. Das Verhalten hat sich also im letzten halben Jahr nicht geändert.

[chris1284]

Schade, das modul scheint vom eigentlichen maintainer auch nicht wirklich supported zu werden. Eine Lösung ist so wohl nicht in sicht

[franky08]

@chris1284

Um alle Funktionen von WVC weiterhin nutzen zu können, habe ich seit Anfang Januar auf meinem Produktivsystem jegliche Updates vermieden. DbLog ist ja seit längerer Zeit nicht upgedatet worden, meine Version ist:

Code Auswählen Erweitern

# $Id: 93_DbLog.pm 6573 2014-09-19 17:08:11Z tobiasfaust $

laut SVN gibt es da nichts Neues, oder?

@justme1968

Und ich hab noch einen alten Thread von mir aufgestöbert und ein Zitat von betateilchen gefunden und demnach funktioniert DbLog(sqlite) NICHT mit plotfork!

Das Problem ist bekannt und wurde hier auch schon vor einer Weile diskutiert. Es scheint sich aber niemand wirklich dafür verantwortlich zu fühlen.

VG
Frank

[Zephyr]

Gleiches Problem bei mir: DBD::mysql::st execute failed: MySQL server has gone away at ./FHEM/93_DbLog.pm line 893.

Habt ihr irgendwas, um den Fehler zu umgehen? Manchmal lässt sich ein herunterfahren der Datenbank halt nicht vermeiden.

Liebe Grüße
Karsten

[chris1284]

um plotfork zu nutzen kannst du nur eines machen : auf sqlite wechseln. ansonsten plotfork abschalten
da das modul vom erschaffer ganz offensichtlich nicht mehr genutzt/supported wird, wird es auch so schnell keinen fix geben.

[ChrisD]

Hallo,

Ich habe vor einiger Zeit dblog geändert damit ich plotfork auf einem entfernten Raspberry Pi mit einer MySQL-Datenbank verwenden kann. Dazu habe ich in der Funktion DbLog_Push die  Zeile

Code Auswählen Erweitern

$dbh->begin_work();
ersetzt durch

Code Auswählen Erweitern

  if ($hash->{DBMODEL} eq "MYSQL") {
      eval {
        $dbh->begin_work();
      };
      if($@) {
        #Log 0,$@;
        DbLog_Connect($hash);
        $dbh->begin_work();
      }
  } else {
    $dbh->begin_work();
  } 
Dies behebt zwar nicht das ursprüngliche Problem das durch das forken kommt, führt aber dazu dass versucht wird die Verbindung wieder zu öffnen wenn Daten geschrieben werden sollen.

Damit habe ich seit 3 Monaten keine Probleme mehr mit plotfork sowie Abbrüchen der VPN-Verbindung zwischen FHEM und MySQL.

Grüße,

ChrisD

[ronny332]

Das Problem scheint nicht rein auf DBLog zu basieren, sondern ist irgendwo MySQL spezifisch.

Zeile 689 nutzt, soweit vorhanden, eine bestehende Verbindung:

Code Auswählen Erweitern

my $dbh = DBI->connect_cached("dbi:$dbconn", $dbuser, $dbpassword, { PrintError => 0 });

Geändert in:

Code Auswählen Erweitern

my $dbh = DBI->connect("dbi:$dbconn", $dbuser, $dbpassword, { PrintError => 0 });

Der Fehler ist weg, die Effektivität aber direkt auch.

Ich teste einfach mal weiter, aber vom Prinzip ist am Code selber nichts falsch. Der Programmierer hat einfach erwartet bei Nutzung des Caches auch eine gültige Verbindung zu bekommen. Das klappt aber scheinbar nicht.

Spontan fiel mir soeben beim Durchschauen der DBLogs (verbose 3) auf, wie schnell und häufig die gepufferten Verbindungen angefragt werden. Wenn hier kein richtiges Locking stattfindet, hat man mal schnell eine bereits verwendete Verbindung in Verwendung (aber dafür fehlt mir der Perl Background).

Keiner Nachtrag:

Die Google Suche nach "perl dbi fork connect_cached" wirft auch direkt passende Probleme aus: http://www.perlmonks.org/bare/?node_id=814605
Ich hoffe doch da den richtigen Ansatz zu haben.

Zweier Nachtrag:

Code Auswählen Erweitern

my $dbh = DBI->connect_cached("dbi:$dbconn", $dbuser, $dbpassword, { PrintError => 0, InactiveDestroy => 1 });

"InactiveDestroy => 1" scheint hier erstmal die Lösung zu sein. Der Fehler ist nicht mehr da, "leider" läuft Fhem bei mir auf einem recht flotten Rechner. Somit kann ich nicht sehen ob die Verbindungen permanent neu erzeugt werden, oder eine weitere Nutzung stattfindet,

[chris1284]

einfacher ist es wirklich von mysql auf sqlite zu gehen, spart man sich auch den mysql overhead (und ggf phpmyadmin). seit dem wechsel läufts problemlos was plots angeht

[ronny332]

in meinem fall laufen mehrere fhem instanzen mit einem einzigen sql server, da ist dann sqlite die falsche wahl.
zu dem bin ich kein freund von "ich weiche aus weil in der software gerade eine einschränkung ist" . viel weiter bin ich gestern nicht mehr gekommen, aber das problem liegt in jedem fall bei der dbi lib von perl, bzw der art wie man sie nutzt. aus effizienz sicht gefällt mir aber nicht, dass für jeden graphen eine verbindung aufgebaut wird, die danach wieder fällt. letztlich kein großes problem, aber nicht "schön".

[rapster]

Würde bitte einer der diese MySql Probleme hat das Ganze mal mit dem Modul im Anhang von http://forum.fhem.de/index.php/topic,42976.msg350386.html#msg350386 testen?

[Tobias]

um plotfork zu nutzen kannst du nur eines machen : auf sqlite wechseln. ansonsten plotfork abschalten
da das modul vom erschaffer ganz offensichtlich nicht mehr genutzt/supported wird, wird es auch so schnell keinen fix geben.

Ich nutze das Modul in allen meinen FHEM-Instanzen und bin ganz stark davon abhängig. Allerdings nutze ich den plotfork Krams nicht weil ich darin keinen Mehrwert (bei mir) sehe. Den hat jemand mal eingebaut um syncron zur FHEM-Entwicklung zu gehen. Am liebsten würde ich es wieder ausbauen - macht nur probleme...

[chris1284]

War das nicht ehr dafür gedacht mehrere plots parallel zu laden um so nicht ewig warten zu müssen? Das abzuschaffen fände ich als verschlechterung.

Edit siehe cmd ref, das auszubauen wäre ein fehler wenn man die cmd ref liest

plotfork
Normalerweise wird die Ploterstellung im Hauptprozess ausgeführt, FHEM wird wärend dieser Zeit nicht auf andere Ereignisse reagieren. Falls dieses Attribut auf einen nicht 0 Wert gesetzt ist, dann wird die Berechnung in weitere Prozesse ausgelagert. Das kann die Berechnung auf Rechnern mit mehreren Prozessoren beschleunigen, allerdings kann es auf Rechnern mit wenig Speicher (z.Bsp. FRITZ!Box 7390) zum automatischen Abschuss des FHEM Prozesses durch das OS führen.

Benutze ja nun sqllite und bin somit die mysql probleme los umd freue mich über das , dank plotfork , sau schnelle laden von 20 plotsmauf einer seite

[Tobias]

Das mit dem "ausbauen" war auch zynisch gemeint. Natürlich werde ich es nicht ausbauen da es einen echten Mehrwert hat. Ich benutze es aber nicht, mein Cubie mit PostGeSQL auf SSD ist mir persönlich schnell genug. Den Plotfork patch hatte jemand mal gebaut, ist für mich aber schwierig zu supporten und zu bugfixen
Abgesehen von der zurZeit fast nicht vorhanden freien Zeit