DBlog Error

Kai-Alfonso · 17 Januar 2018, 14:23:54

Moin,

ich muss auch noch einmal mit einem Ding dazwischengrätschen - bin zwar nicht 100%ig sicher, ob es an DbLog liegt, zeitlich liegt es aber sehr nah beisammen (Umstellung und Probleme)

und zwar: fhem lässt sich nicht mehr gescheit stoppen. Ein shutdown restart hängt immer bei:

Code Auswählen

2018.01.17 14:14:52 1: HMCCURPC: Found 1 threads. Stopping ...
2018.01.17 14:14:54 2: DbLog DBLog waiting for shutdown
2018.01.17 14:14:56 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
2018.01.17 14:15:03 1: Including fhem.cfg
2018.01.17 14:15:03 1: telnetPort: Can't open server port at 7072: Die Adresse wird bereits verwendet. Exiting.

scheint wohl als wäre er nicht sauber beendet (Telnet Server läuft noch) ist, wenn er den neustart versucht.

ein /etc/init.d/fhem stop bringt folgendes:

Code Auswählen

root@fhem:~#/etc/init.d/fhem stop
Stopping fhem...

und da hängt er bis ich abbreche.

ein killall perl killt dann alle Prozesse und ich kann fhem normal wieder über den Daemon starten.

Jemand ne Idee ob es an Dblog liegt?

DS_Starter · 17 Januar 2018, 20:40:10

@Kai, es kann einen Zusammenhang geben. Wir haben ja bereits schon festgestellt, dass deine DB lange braucht um Daten wegzuschreiben. Beim Shutdown wird ein finaler Schreibprozess initiiert um die Daten im Cache in die DB zu schreiben. Möglicherweise ist dein "shutdownWait" Wert noch zu klein. In der angehängten Version 3.6.4 habe ich die Shutdown-Funktion ein wenig erweitert.
Spiele diese Version mal ein und teste mit verschiedenen "shutdownWait"-Werten. Auszuschliessen ist natürlich auch nicht dass ein anderes Modul mit reinspielt (SONOS, HMCCURPC habe ich nicht im Einsatz).
Bei mir habe ich dergleichen noch nicht festgestellt.

@kumue, bzgl. dem Lesen der conf habe ich in der angehängten Version einen Zeichenfilter implementiert, den du mit dem Attr "useCharfilter = 1" aktivieren kannst. Probiere mal aus, ob dann der UTF8 Key bei dir erkannt wird. Wie gesagt, wenn du das conf-File neu eintippen (nicht kopieren) würdest, bin ich überzeugt ginge es auch. Aber wenn der charfilter hier auch wirken würde, wäre das eine generell gute Lösung für zukünftige Fälle.

Die globalen Rechte meines testusers siehst du im Anhang. Ein "show grants" ausgeführt mit DbRep

Code Auswählen

set ... sqlCmd show grants

bringt die Infos des zweiten Screenshots. Bei wird "FILE" mit ausgegeben.
Entziehe ich dem User das Recht in der phpMyAdmin-Maske kommt bei mir exakt der gleiche Fehler wie bei dir.
Wenn du das Rechteproblem löst, wird der Dump auch funktionieren.

LG,
Heiko

kumue · 17 Januar 2018, 21:20:45

UFT.. unverändert
Habe die conf-Datei neu angelegt und alles eingetippt.
Deine neue Version installiert, das Attribute gesetzt. Neustart.
Im Log finden sich nur diese beiden Zeilen:

Code Auswählen

2018.01.17 21:08:42 3: DbLog myMariaDB - Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2018.01.17 21:08:42 3: DbLog myMariaDB - Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser

Was mir auffiel:
Der STATE von DbLog steht jetzt ca. 20sec auf initialized bevor das connected kommt..

Wegen den Rechten muss ich noch schauen...

DS_Starter · 17 Januar 2018, 21:33:28

ZitatUFT.. unverändert.

Sag mal ... dumme Frage, du verwendest doch configDB. Du importierst doch das editierte conf-File in configDB, oder ??

ZitatWas mir auffiel:
Der STATE von DbLog steht jetzt ca. 20sec auf initialized bevor das connected kommt..

Kein Grund zur Beunruhigung.

kumue · 17 Januar 2018, 21:40:11

Zitat von: DS_Starter am 17 Januar 2018, 21:33:28
Sag mal ... dumme Frage, du verwendest doch configDB. Du importierst doch das editierte conf-File in configDB, oder ??
Kein Grund zur Beunruhigung.

Bingo, das wars.. UFT8 1

Nachdem ich utf8 in die conf eingetrug, habe ich die Datei nicht noch mal gelöscht und wieder importiert.
Danke für Deine Unterstützung, daran hätte ich jetzt nicht gedacht.

Wegen dem dump mache ich morgen weiter.

Danke nochmals und gute Nacht !

DS_Starter · 17 Januar 2018, 21:44:14

Gute Nacht !

Kai-Alfonso · 18 Januar 2018, 07:20:12

Zitat von: DS_Starter am 17 Januar 2018, 20:40:10
@Kai, es kann einen Zusammenhang geben. Wir haben ja bereits schon festgestellt, dass deine DB lange braucht um Daten wegzuschreiben. Beim Shutdown wird ein finaler Schreibprozess initiiert um die Daten im Cache in die DB zu schreiben. Möglicherweise ist dein "shutdownWait" Wert noch zu klein. In der angehängten Version 3.6.4 habe ich die Shutdown-Funktion ein wenig erweitert.
Spiele diese Version mal ein und teste mit verschiedenen "shutdownWait"-Werten. Auszuschliessen ist natürlich auch nicht dass ein anderes Modul mit reinspielt (SONOS, HMCCURPC habe ich nicht im Einsatz).
Bei mir habe ich dergleichen noch nicht festgestellt.

Guten Morgen Heiko - ich habe jetzt mal die neue Version eingespielt und ShutdownTimer=5 gesetzt - shutdown und shutdown restart geht jetzt ohne Probleme

Danke dafür

DS_Starter · 18 Januar 2018, 09:02:25

Guten Morgen,

prima. Dann übernehme ich das mit in das SVN.

LG,
Heiko

kumue · 18 Januar 2018, 09:53:44

Moin Heiko,
der serverside Dump läuft jetzt auch.

Code Auswählen

2018.01.18 09:41:54 3: DbRep myDbRep - Database dump finished successfully. 
2018.01.18 09:41:54 3: DbRep myDbRep - Finished backup of database fhem - total time used: 88 seconds
2018.01.18 09:41:54 3: DbRep myDbRep - Size of backupfile: n.a.
2018.01.18 09:41:54 3: DbRep myDbRep - Number of exported datasets: 3606858
2018.01.18 09:40:26 3: DbRep myDbRep - Starting dump of database 'fhem', table 'history'
2018.01.18 09:40:26 3: DbRep myDbRep - Searching for tables inside database fhem....
2018.01.18 09:40:26 3: DbRep myDbRep - ################################################################
2018.01.18 09:40:26 3: DbRep myDbRep - ###             New database serverSide dump                 ###
2018.01.18 09:40:26 3: DbRep myDbRep - ################################################################

Das File liegt im /var/lib/mysql

Code Auswählen

-rw-rw-rw- 1 mysql mysql 303M Jan 18 09:41 /var/lib/mysql/fhem_history_2018_01_18_09_40.csv

Eine kleine Sache, die nicht weiter stört... wieso kann die Dateigröße nicht angezeigt werden ?

Code Auswählen

2018.01.18 09:41:54 3: DbRep myDbRep - Size of backupfile: n.a.

DS_Starter · 18 Januar 2018, 10:01:15

ZitatEine kleine Sache, die nicht weiter stört... wieso kann die Dateigröße nicht angezeigt werden ?

Weil ich das bisher nicht beim serverside backup implementiert habe. Es hängt nämlich davon ab, ob der User die interne Versionsverwaltung nutzt und das Attr "dumpDirLocal" gesetzt hat oder nicht. Sonst komme ich mit der Routine nicht an die Daten.
KAnn ich mal mit vorsehen. Sind dann ein paar If's, elses mehr.

Stimmt nicht, habe ich schon implementiert. Aber das Modul muss ran kommen. -> "dumpDirLocal" setzen !

Prima, das es nun klappt !

LG,
Heiko

kumue · 18 Januar 2018, 17:32:46

das Verzeichnis war aber gesetzt auf

Code Auswählen

/opt/fhem/dumps_FHEM

Code Auswählen

drwxr-xr-x 2 fhem dialout 4096 Jan 16 11:15 dumps_FHEM

exportToFile wird auch in dieses Verzeichnis geschrieben....

DS_Starter · 18 Januar 2018, 17:45:24

du hattest doch geschrieben:

Zitat
Das File liegt im /var/lib/mysql

Dann musst du auch setzen "dumpDirLocal = /var/lib/mysql".

exportToFile ist eine andere Funktion und verwendet das Attribut "expimpfile".

kumue · 18 Januar 2018, 18:48:14

ich hatte mich gewundert, daß das File "selbstständig" ins /var... geschrieben wurde und nicht ins schon vorher gesetzte /opt/fhem/dumps_FHEM...

weil in der commandref steht ja

ZitatDer Dump wird durch den MySQL-Server erstellt und per default im Home-Verzeichnis des MySQL-Servers gespeichert.
[...]
Das Zielverzeichnis kann mit dem Attribut "dumpDirRemote" verändert werden.

DS_Starter · 18 Januar 2018, 18:55:19

Ja, stimmt ja auch, ins Home des MySQL-Servers.

Bei serverside Dump steuerst du das Zielverzeichnis mit dem Attribut "dumpDirRemote", das ist ein Verzeichnis welches (im Normalfall) auf einem entfernten Server (z.B. Synology) vorhanden und für den MySQL-Server zugreifbar sein muss. Will man es FHEM bekannt machen, muss es gemountet sein und dieser Mountpoint in "dumpDirLocal" hinterlegt werden.

Sonderfall ist eben wenn der DB-Server mit auf Raspi läuft und "dumpDirRemote" und "dumpDirLocal" auf das gleiche Verzeichnis gesetzt werden.
Ich hoffe ich habe es in der Commandref einigermaßen verständlich beschrieben

Aber das ist eigentlich der falsche Thread, weil es geht inzwischen um DbRep-Fragen ...

LG,
Heiko

kumue · 18 Januar 2018, 18:58:01

jo, CR ist verständlich beschrieben..
wieder das alte Thema... "Wer lesen kann... "
Ich bin jetzt still hier...
Danke nochmals !!!