Ich hatte ziemliche Probleme mit der Nutzung von fork bei XBMC und STV in Verbindung mit DbLog (http://forum.fhem.de/index.php/topic,24466.0.html). Wenn sich der fork-Prozess beendet, dann wurde immer das DB-Handle im Hauptprozess zugemacht.
Ich habe ein Flag für DBI gefunden, welches das Schließen des Handles verhindert: InactiveDestroy
Vielleicht kennt ihr das ja schon, aber für mich war das neu.
Ich habe daher in XBMC und STV den Code, der nach dem Fork die File-Deskriptoren schließt (kopiert aus Blocking.pm) um folgende Zeile erweitert. Die setzt nach dem Fork sofort diese Flag für das DBI-Handle:
foreach my $d (sort keys %defs) { # Close all kind of FD
my $h = $defs{$d};
NEU ---> $h->{DBH}->{InactiveDestroy} = 1 if ($h->{TYPE} eq 'DbLog'); <--------------
TcpServer_Close($h) if($h->{SERVERSOCKET});
if($h->{DeviceName}) {
require "$attr{global}{modpath}/FHEM/DevIo.pm";
DevIo_CloseDev($h,1);
}
}
Evtl. sollte die Zeile auch in den Ursprungscode in Blocking.pm übernommen werden? Ist ein bisschen "hackisch", dass damit Blocking etwas von DbLog weiß, aber ich hab keine elegantere Lösung gefunden.
Habs eingecheckt.
Danke.
Hallo,
obige eingefügte Zeile verursacht bei mir ständig folgende Meldungen auf der Konsole:
Use of uninitialized value in string eq at FHEM/Blocking.pm line 85.
Use of uninitialized value in string eq at FHEM/Blocking.pm line 85.
Use of uninitialized value in string eq at FHEM/Blocking.pm line 85.
Use of uninitialized value in string eq at FHEM/Blocking.pm line 85.
Wenn ich den Code richtig verstehe, habe ich wohl ein Device ohne bzw mit leerem TYPE?? Wie kann ich das herausfinden?
Gruss
Tobias
Je nachdem wieviele Geräte du hast, ist es evtl. am einfachsten die einmal durchzuklicken? Oder halt in perl ne foreach-Schleife, die alle Devices entsprechend rausprintet.
Kann das denn im Normalbetrieb vorkommen, dass ein Device kein TYPE hat?
Wie man solche Geraete findet, habe ich gefuehlt schon zehnmal beschrieben, bitte danach suchen...
Zitat von: rudolfkoenig am 22 Juni 2014, 16:48:44
Wie man solche Geraete findet, habe ich gefuehlt schon zehnmal beschrieben, bitte danach suchen...
Ist aber mangels griffigen Suchwort nicht so leicht zu finden. Ein shutdown restart hilft allerdings weiter - es findet sich dann folgende Meldung im Log:
2014.06.22 17:33:37.199 0: Strange call for typeless FileLog_az_Thermostat_ClimRT_tr: ShutdownFnZitat von: vbs am 22 Juni 2014, 16:45:30
Kann das denn im Normalbetrieb vorkommen, dass ein Device kein TYPE hat?
Ich habe "rename" bzw. "autocreate" in Verdacht. Obiges Beispiel ist dadurch entstanden, dass ich den Channel az_Thermostat_ClimRT_tr in az_Thermostat_Clima (neue Bezeichnung beim RT-DN) umbenannt habe. autocreate benennt im Hintergrund dann auch das zugehörige Filelog um.
Ebenso sehe ich solche Meldungen auch, wenn ich HomeMatic Devices erstmalig in FHEM definiere. Die durch das Pairing automatisch vergebenen Device Namen benenne ich dann natürlich um.
2014.06.14 22:39:00 0: Strange call for typeless CUL_HM_HM_LC_Bl1PBU_FM_26A65A: ShutdownFn
2014.06.22 16:52:29 0: Strange call for typeless CUL_HM_HM_LC_Bl1PBU_FM_28F588: ShutdownFn
Kann es sein, dass der rename (in bestimmten Fällen/immer??) ein solches "typeless" Device hinterlässt?
Gruss
Tobias
ZitatIst aber mangels griffigen Suchwort nicht so leicht zu finden.
Wenn ich in Google "FHEM device kein TYPE rudolfkoenig" eingebe, dann musste ich zweimal klicken, um hierher zu kommen:
http://forum.fhem.de/index.php/topic,16172.msg105916.html#msg105916
ZitatIch habe "rename" bzw. "autocreate" in Verdacht.
Das ist (wenn ueberhaupt) nur in Ausnahmefaellen so. Wenn es reproduzierbar ist, werde ich es natuerlich fixen, dazu brauche ich aber ein Anleitung.
Zitat von: rudolfkoenig am 23 Juni 2014, 18:35:10
Wenn ich in Google "FHEM device kein TYPE rudolfkoenig" eingebe, dann musste ich zweimal klicken, um hierher zu kommen:
http://forum.fhem.de/index.php/topic,16172.msg105916.html#msg105916
Danke - ich habe naiverweise die interne Suche im Forum bemüht... Nichts geht über Dr. Google 8)
Zitat
Das ist (wenn ueberhaupt) nur in Ausnahmefaellen so. Wenn es reproduzierbar ist, werde ich es natuerlich fixen, dazu brauche ich aber ein Anleitung.
Wenn ich es reproduzieren kann, melde ich mich hier nochmal...
Gruss
Tobias
Ich stelle jetzt einfach mal die kühne Behauptung auf, dass die in Blocking.pm vorgenommene Änderung für sämtliche hier im Forum in den letzten Tagen gemeldeten Problemen mit Verbindungs- und Loggingproblemen des Moduls 93_DbLog.pm verantwortlich ist.
Da ich weder DbLog noch configDB Nachrichten in Detail lese, habe ich keinen Ueberblick. Kannst Du schreiben, welche Probleme Du meinst? Das hier vorher gemeldete kann ja nicht sein.
Ist möglich, wie kommst du drauf?