Hi All
ich als SQL-Dummie hab keine Ahnung warum er in den Timeout läuft.
seit heute steht aller 1 Minute im log
2013.02.21 11:08:02 2: DBLog error: MySQL server has gone away
2013.02.21 11:08:02 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user xxx
2013.02.21 11:08:02 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
2013.02.21 11:08:02 2: DBLog retry ok.
2013.02.21 11:08:07 2: DBLog error: MySQL server has gone away
2013.02.21 11:08:07 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user xxx
2013.02.21 11:08:07 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
2013.02.21 11:08:07 2: DBLog retry ok.
2013.02.21 11:09:07 2: DBLog error: MySQL server has gone away
2013.02.21 11:09:07 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user xxx
2013.02.21 11:09:07 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
2013.02.21 11:09:07 2: DBLog retry ok.
loggen tut er aber trotzdem.
Kann mir einer auf die Sprünge helfen.
Ach ja: fhem 5.3 Dev mit Mysql auf Synology NAS.
Status Update
ich habe anscheinend das auslösende Modul gefunden
2013.02.21 21:00:06 1: PRESENCE (HandyAndy): 'which hcitool' returns: /usr/syno/bin/hcitool
2013.02.21 21:00:08 1: PRESENCE (HandyAndy) - hcitool returned: AndyiPhone
2013.02.21 21:00:08 1: PRESENCE_ProcessLocalScan: HandyAndy|0|present|AndyiPhone
2013.02.21 21:00:08 2: DBLog error: MySQL server has gone away
2013.02.21 21:00:08 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user xxx
2013.02.21 21:00:08 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
2013.02.21 21:00:08 2: DBLog retry ok.
denn nach deaktivieren von Presence läuft der DBlog wieder ohne Error.
Problem gelöst.
DB war defekt.
Neue DB erstellt und Datensätze importiert und alles ist wieder schön.
Leider hilft bei mir nur das Abschalten des PRESENCE Moduls.....
Eine neue DB hat nicht geholfen.....
Gibt es einen Zusammenhang zwischen PRESENCE und DBLog?
Gruß Michael
Hi All,
Also ich hab den oben beschriebenen Fehler auch,
allerdings kann ich ausschließen, das es was mit Presence zu tun hat:
1)ich hab in den alten Logs gegraben, ich hab diesen Fehler seit dem update am 18.1.2013 und da gab's
das presence modul noch gar nicht.
2)Ich hab den Fehler nur auf dem Raspberri PI und nicht auf der QNAP auf beiden läuft die gleiche DbLog
Definition und auf die gleiche MYSQL-DB (auf der QNAP).
3) Ich hab ein paar debug Ausgaben ins DbLog Modul eingebaut, es sieht für mich soo aus, daß der Fehler dann auftritt, wenn länger als ca. 20 Sekunden nichts geloggt wird - und dann kommt im stderr auch eine Fehlermeldung wie DBD::mysql::db do failed: MySQL server has gone away at ./FHEM/93_DbLogMH.pm line xxx...
da kommt der Fehler einmalig, und dann werden 5-10 events unmittelbar hintereinander geloggt- ohne Fehler.
dann wieder 20++ Sekunden kein logging, dann wieder 1 Fehler, 5-1o events ok....
Ich vermute, dass es irgendwas mit TCP-Timern zu tun hat und möchte desswegen euer Feedback zu folgender Frage:
auf welcher Platform kommt der Fehler - und evtl. wer hat den Fehler nicht auf welcher Platform?
z.B: ein uname -a (im SSH Fenster):
da hab ich den Fehler:
pi@MH-RPI-1 /opt/fhem $ uname -a
Linux MH-RPI-1 3.6.11+ #362 PREEMPT Tue Jan 22 14:52:21 GMT 2013 armv6l GNU/Linux
und auf der qnap läuft's ok:
[/opt/lib/FHEM] # uname -a
Linux MH-QNAP419P 2.6.33.2 #1 Mon Aug 15 23:56:06 CST 2011 armv5tel unknown
l.g. erwin
Hallo zusammen,
das Problem wurde soeben im SVN gefixt. Bitte morgen updaten und einmal neustarten, dann sollte das Problem weg sein.
Viele Grüße
Markus
Hi Markus,
danke für den Fix,
ich hab noch eine Frage dazu:
besteht der fix aus der Änderung im Blocking.pm?
Falls die Antwort ja ist, wären mir einige komische Phänomene klar:
1) Warum ich die Fehlermeldung seit 18.1. habe, wobei es da noch kein PRESENCE Modul gab.
2) Warum es bei mir nur auf einer Plattform (Raspberry) auftrat und nicht auf der QNAP.
3) Warum ich die Fehlermeldung nach apply des fixes noch immer hatte.
Immer vorausgesetzt, dass deine Antwort auf die Frage ja ist, folgende Antworten auf meine eingenen Statments:
1) OWServer verwendet (mittlels Attribut nonblocking) ebenfalls fork() - und terminiert mit exit 0. Allerdings nicht via Blocking.pm, sondern eine eigene Routine im Modul.
2) Ich habe OWServer und PRESENCE nur auf dem RPI im Einsatz.
3) Der Fehler ist nun weg, weil ich im OWServer das nonblocking Attribut gelöscht hab! Der Fehler ist jetzt mit Aktivieren der Attr. nonblocking eindeutig reproduzierbar.
Danke jedenfalls an ALLE Beteiligten für den fix!
l.g. erwin
Hallo Erwin,
meine voraussehbare Antwort lautet: Ja
Bei OwServer sollte das auch geändert werden. Generell schon aus dem Grund, damit es einheitlich ist.
Viele Grüße
Markus
Hallo,
auch von mir herzlichen Dank für den Fix.