plotfork und dblog

[marvin78]

Also für mich ist es ohnehin kein Problem (eher was nervendes) weil ich ja configDB nutze (wobei das schon ein Problem sein kann, wenn mySQL noch nicht da ist, wenn fhem startet ). Mir geht es um das grundsätzliche Verhalten was, meiner Ansicht nach, nicht korrekt ist.

[JoeALLb]

Es gibt genug Gründe, warum DBLog nicht gelöscht werden sollte, aber dass ein Workaround hilfreich ist, ist natürlich auch logisch.
Beispielsweise wurde bei mir letztens DBLog beim Start gelöscht, als MySQL die Datenbank reindiziert hat und deshalb nicht (schnell genug) geantwortet hat.

[betateilchen]

Beispielsweise wurde bei mir letztens DBLog beim Start gelöscht, als MySQL die Datenbank reindiziert hat

jepp, das ist einer der Fälle, in denen das Required-Start nicht weiterhilft, weil der Dienst ja komplett gestartet ist (sonst könnte die Reindexierung nicht laufen)

[betateilchen]

warum hat es nicht gereicht nach dem fork das original handle nicht zu schliessen sondern in ruhe zu lassen.

Weil es überhaupt keine unterscheidbaren Handles gibt...

Anders gesagt: Völlig egal, ob Du ein disconnect() überhaupt verwendest oder nicht, die Verbindung wird vom fork kontrolliert und nicht von DbLog. Du kannst das Testen, indem Du alle disconnects im Modul auskommentierst - es wird das Fehlerverhalten nicht beeinflussen. Die einzige Chance ist die jetzt eingebaute Fehlerbehandlung.

Ob das Ganze jetzt MySQL spezifisch ist, kann ich noch nicht beurteilen. WIe schon gesagt: SQLITE ist davon nicht betroffen. Und Postgre hab ich nicht im Einsatz.

[justme1968]

die erklärung kann aber nicht nicht ganz vollständig sein.

wie kann die lib im parent mit bekommen das es ein fork gab und wie kann etwas das nur im child passiert die connection im parent beeinflussen. und selbst wenn es das über die conenction irgendwie schafft sollte es spätestens dann funktionieren wenn man das disconnect weg lässt. spätestens dann gibt es keinen unterschied mehr zu mehreren connections aus unterschiedlichen prozessen. und das kann sogar mysql.

irgendetwas stimmt da immer noch nicht glaube ich.

[betateilchen]

sollte es spätestens dann funktionieren wenn man das disconnect weg lässt.

Tut es aber nicht - probiers aus, wenn Du es nicht glaubst.

spätestens dann gibt es keinen unterschied mehr zu mehreren connections aus unterschiedlichen prozessen.

Theoretisch...

und das kann sogar mysql.

Mag sein, dass MySQL das kann.

Die Frage ist aber, ob die DBD / DBI das kann, so weit in die Tiefe bin ich nicht gegangen.
Am DbLog Modul liegt es nach meinen Tests und der daraus gebildeten Meinung nicht.

[justme1968]

ich glaube dir

das bedeutet aber nicht das ich das verhalten verstehe oder sogar sage das es so korrekt ist

[betateilchen]

Ich habe auch nirgends behauptet, dass das Verhalten korrekt sei. Aber ich habe keine große Lust, perl Module ausserhalb von fhem zu debuggen.

Der vorgeschlagene Patch behebt das Problem recht zuverlässig, den anderen offenen Punkt (DbLog wird nicht gestartet, wenn MySQL wegen Auslastung noch nicht verfügbar) solle man separat betrachten.

[Tobias]

Wenn der Patch soweit io ist kann ich ihn einchecken. Sagt Bescheid.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

Der Patch hängt  in meinem Beitrag von Sonntag.

[betateilchen]

Es gibt genug Gründe, warum DBLog nicht gelöscht werden sollte, aber dass ein Workaround hilfreich ist, ist natürlich auch logisch.
Beispielsweise wurde bei mir letztens DBLog beim Start gelöscht, als MySQL die Datenbank reindiziert hat und deshalb nicht (schnell genug) geantwortet hat.

Im Developer-Bereich habe ich gerade eine Modulversion gepostet, die auch mit noch nicht existierenden Datenbankverbindungen zurechtkommen sollte.

http://forum.fhem.de/index.php/topic,20847.msg154874.html#msg154874

[jschmitt]

Hallo,

ich weiß nicht recht ob ich hier richtig bin. Bei Bedarf bitte verschieben.

Mein Problem: DBLog nach Neustart des GANZEN Servers mit MySQL (auf QNAP NAS).

Fehler:
"Error messages while initializing FHEM:
configfile: Can't connect to database."

LogFile:
2014.05.22 00:52:48 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2014.05.22 00:52:48 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 5671
2014.05.22 00:52:48 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established

UND:

XML-Verarbeitungsfehler: Kein Element gefunden
Adresse: http://10.255.255.5:8083/fhem/SVG_showLog?dev=PLOT_Kurse&logdev=KurseLOG&gplotfile=PLOT_Kurse&logfile=history&pos=
Zeile Nr. 2, Spalte 1:

Ratlos...

Viele Grüße,

Johannes

[Tobias]

Johannes,
ich würde sagen das du den FHEM Start nicht vom DB-Start abhängig gemacht hast. Da fehlen bei dir die Abhängigkeiten im FHEM-Startscript

[betateilchen]

oder Du hast in deiner Konfiguration die SVG plots vor dem DbLog definiert.

[jschmitt]

Hallo,
@betateilchen: die Reihenfolge ist korrekt
@Tobias: # Required-Start: xxx
                Wo ist diese Abhängigkeit einzustellen?
                In meinem Start- Script ist so etwas (noch?) nicht vorhanden.

Zur Erklärung: Alles läuft auf einem QNAP-NAS mit Optware.
Der Fehler tritt auch nur nach einem Reboot des Gesamtsystems auf
(welchen ich einmal in der Woche machen muß, sonst vergißt mein
NAS externe Geräte wie USV etc...)
Mache ich bei laufendem (NAS-) System einen "Shutdown Restart",
werden mir die Grafiken wieder angezeigt.

Es sieht mir so aus, daß fhem bzw. SVG-PLOT beim Start nicht auf mysql wartet.
Im Logfile sehe ich ja den mißlungenen Verbindungsaufbau, aber später steht
da ja "Connection established".
Nur im Frontend bekomme ich keine Grafik. Stoße ich dann einen "Shutdown Restart"
an, klappt es wieder mit der Anzeige.

Habe ich was übersehen bzgl. derStart- Reihenfolge oder sollte mein NAS nach dem Neustart
so sehr mit mysql (oder mysql selbst) beschäftigt sein?
Oder soll ich einen cron- Job einrichten, der dann fhem nochmal neu startet?
Ich meine mich erinnern zu können daß das Anfang April oder so mal reibungslos lief...

Hat wer eine solche Konstellation und eine Lösung?

Viele Grüße,

Johannes