Hallo,
ich habe seit einiger Zeit auf DbLog umgestellt funktioniert auch soweit alles super. In letzter Zeit habe ich einige Schwierigkeiten mit meinen SQL Server (Qnap NAS). Dieser ist von Zeit zu Zeit nicht erreichbar (ist aber auch egal).
Leider kommt es jedoch zum Absturz von FHEM wenn ich meinen SVG Plot öffne mit folgender Fehlermeldung
2015.11.14 09:40:03 3: Defining DbLog SVG-Plots with :CURRENT is deprecated. Please define DbLog SVG-Plots with :HISTORY instead of :CURRENT. (define <mySVG> SVG <DbLogDev>:<gplotfile>:HISTORY)
DBD::mysql::st execute failed: MySQL server has gone away at ./FHEM/93_DbLog.pm line 1031.
Der SVG log wurde wie folgt angelegt
define testplot SVG logdb:CURRENT
Vielleicht sollte man hier mal nachsehen.
Könnte Ihr mir hierzu weitere Infos geben?
Naja. Du musst sehen, dass dein SQL-Server verfügbar ist.
Natürlich sollte FHEM nicht unbedingt abstürzen. Dein
(ist aber auch egal)
lässt mich jedoch daran zweifeln, dass du ernsthaft auf der Suche nach einer Lösung bist.
Das "ist aber auch egal" sollte sich darauf Beziehen warum der Server absützt was jedoch nicht Thema sein soll....
so heute nochmals das Problem gehabt
DBD::mysql::st execute failed: MySQL server has gone away at ./FHEM/93_DbLog.pm line 1031.
Nach dem FHEM dann nicht mehr erreichbar war habe ich den Prozess per Putty gestoppt und neugestartet, danach funktioniert wieder alles,
Zitat von: mane88 am 14 November 2015, 09:48:22
Hallo,
ich habe seit einiger Zeit auf DbLog umgestellt funktioniert auch soweit alles super. In letzter Zeit habe ich einige Schwierigkeiten mit meinen SQL Server (Qnap NAS). Dieser ist von Zeit zu Zeit nicht erreichbar (ist aber auch egal).
Leider kommt es jedoch zum Absturz von FHEM wenn ich meinen SVG Plot öffne mit folgender Fehlermeldung
Ich hab auch DBLog im Einsatz. Meine DB und Fhem läuft auf einem BananaPro (nicht auf NAS wie bei dir) und hab aber auch die selbe Meldung vor ein paar Tagen gehabt. Hab eine Image-Sicherung der SD-Card zurückgespielt und seitdem gehts wieder. Bei mir ist aber FHEM nicht abgestürzt, nur Plots wurden nicht mehr aktuallisiert.
Wenn Fhem einfriert ... hast du die Config auch in der DB? Würde es erklären ... Worauf hast du Fhem laufen? Auch auf dem NAS oder einen Raspi? Wenn Fhem separat läuft SD-Card sichern, mysql installieren und testweise umziehen. Vielleicht ist es ein Netzwerkproblem und durch offene Connections hängt dann dein Fhem.
Nicht die Lösung aber mit Ausschlussverfahren kommst vielleicht auf ein stabil laufendes Fhem.
Also FHEM läuft auf dem Rasp inkl. config
nur die Logdaten werden in eine MSQL DB auf dem NAS geschrieben
Zitat von: kadettilac89 am 30 Dezember 2015, 20:58:39
Wenn Fhem einfriert ... hast du die Config auch in der DB? Würde es erklären ...
Würde es übrigens nicht, die Config würde nur beim Start von FHEM von der DB gelesen und nicht während des Betriebs.
hast du plotfork aktiv?
Zitat von: Benni am 31 Dezember 2015, 10:32:57
Würde es übrigens nicht, die Config würde nur beim Start von FHEM von der DB gelesen und nicht während des Betriebs.
ok, ich ging davon aus, dass die DB auch im laufenden Betrieb benötigt wird um z. B. Events aus Autocreate zu schreiben. Ich hab mich nicht näher mit ConfigDB befasst und wusste nicht, dass die Änderungen erst in Files oder im Speicher gepuffert werden.
Zitat von: stromer-12 am 31 Dezember 2015, 10:58:16
hast du plotfork aktiv?
Ich behaupte mal nein, wo kann ich dies expliziet nachsehen. Habe es meines Wissens nicht selbstständig aktiviert.
plotfork ist ein Attribut von FHEMWEB (http://fhem.de/commandref_DE.html#FHEMWEB).
(Das quasi "Standard"-FHEMWEB-Device heißt meist WEB und hört auf Port 8083)
Ich habe bei mir plotfork aktiv, aber einen Workaround hier aus dem Forum eingebaut.
Aber es gibt trotzdem noch Stellen wo Fhem auch bei mir abschmiert, wenn Fehler beim Abruf auftreten:
2016.01.02 13:20:46.632 1: PERL WARNING: DBD::mysql::st execute failed: MySQL server has gone away at ./FHEM/93_DbLog.pm line 1047.
Can't use string ("") as a SCALAR ref while "strict refs" in use at ./FHEM/98_logProxy.pm line 926.
plotfork ist bei mir nicht aktiv, in keinem meiner beiden Webservices hab ich dieses Attribut
Ich muss zugeben dass ich etwas verblüfft über die Diskussion bin?
Aus meiner Sicht wäre es sogar gewünscht, dass FHEM stehenbleibt oder sich (sauber) beendet, wenn der DBLog nicht mehr erreichbar ist. Die Datenbank (und die Verbindung dazu) sollte doch mindestens so stabil sein, wie die darüberliegende Anwendung. Vielleicht sind die Events/Logs nicht kritisch im eigentlichen Sinn bei mir, aber eigentlich macht es doch Sinn Zeit darin zu investieren, dass die Stabilität der DB erhöht wird und nicht fhem ohne sie weiterläuft?
Da ich heute etwas mit meiner MySQL Installation gespielt habe, ist mir dieser Faden hier eingefallen.
Folgendes konnte ich beobachten, Fhem stürzt erst dann ab, wenn zum Beispiel Daten für ein SVG aus der Datenbank geladen werden sollen. Im Log findet sich dann die oben erwähnte Meldung: MySQL server has gone.
Der Absturz ist die eine Sache, mehr stört, dass in der Zwischenzeit, bis zum Absturz, auch keine Daten geloggt werden. Darüber gibt es keine Information (global verbose steht auf 3).
Ich habe den MySQL Server dabei "nur" durchgestartet. Eine Erneuerung der Verbindung wäre also möglich gewesen. Zum Zeitpunkt des Absturzes war der Server bereits wieder gestartet und verfügbar.
Ist bei mir identisch. FHEM läuft "einwandfrei" weiter, loggt aber keine Daten mehr. Sobald man auf die Daten zugreifen will mit SVG oder auch mit meiner Handyapp (FHEMapp) stützt FHEM vollständig ab. Da hilft dann nur noch ein Neustart vom Server/Prozess. Kann unter umständen halt doof sein wenn man vor der Tür steht XD
Daten werden bei mir weiter geloggt. FHEM stürzt nur bei bestimmten Fehlern ab. Bei mir taucht dann immer eine Fehlermeldung mit SCALAR auf.
stromer on tour
Hier gleiches Problem. Gestern QNAP-NAS mit der MySQL-DB neugestartet, erst heute ist Fhem auf dem Cubietruck nach einem Remotezugriff mit folgendem Fehler abgestürzt. Daten wurden bis zum Absturz weiterhin geloggt, d.h. MySQL-DB war erreichbar.
2016.01.25 08:52:44 1: PERL WARNING: Use of uninitialized value $type in concatenation (.) or string at (eval 317548) line 17.
DBD::mysql::st execute failed: MySQL server has gone away at ./FHEM/93_DbLog.pm line 1031.
2016.01.25 08:52:53 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Connection refused
Das ist bei mir auch so. fhem bekommt anscheinen das fehlen der Datenbank nicht mit, bis Daten abgefragt werden.
Auch mit dem dem Modul GetState kann der Verbindungszustand zur Datenbank nicht festgestellt werden.
Meines erachtens fehlt eine Überwachung der Datanbankverbindung, die entweder Alarm gibt wenn die DB nicht mehr verfügbar ist oder alle paar Minuten versucht die Verbindung wieder aufzubauen.
Peter
Zitat von: Pnemenz am 27 Januar 2016, 13:52:12
Meines erachtens fehlt eine Überwachung der Datanbankverbindung, die entweder Alarm gibt wenn die DB nicht mehr verfügbar ist oder alle paar Minuten versucht die Verbindung wieder aufzubauen.
Eine gesonderte Überwachung der Datenbankverbindung (z.B. über ein PRESENCE-Device) hilft hier wohl nicht weiter, oder? Denn der Zeitpunkt, in welchem FHEM Daten aus der Datenbank abrufen will (und bei fehlender Verbindung zum Datenbank-Server "hängt" oder abstürzt), ist ja nicht vorhersehbar, so dass ein Presence-Device den Verbindungsabbruch zur Datenbank unter Umständen erst mitbekäme, wenn es schon zu spät ist.
Eine Art "Failsafe"-Lösung scheint es derzeit noch nicht zu geben?
Gruß,
alpha1974
Schaut mal hier:
http://forum.fhem.de/index.php/topic,42976.msg405627.html#msg405627 (http://forum.fhem.de/index.php/topic,42976.msg405627.html#msg405627). Hilft das?
Hatte heute auch meinen sql durchgestartet und festgestellt, dass fhem danach nur per ssh neu zu starten war.
@viegener:
Dein Ansatz ist zwar schon verständlich, aber ich logge nur Temperaturen in die db und wenn danach fhem plötzlich steht und ich die Wohnung mit der KeyMatic nicht mehr aufbekomme , ist das nicht so ideal. (Nur als Bespiel, hab ja eh den Schlüssel auch mit :-P)