[erledigt] SubProcess - Umgang mit %logInform-Eintrag für Log-Handler nach fork

[DS_Starter]

Hallo zusammen,

ich eröffne mal einen Thread zu einer Problematik die mir im Verlauf des Fixing in diesem Thread aufgefallen ist.

Der konkrete Anlaß war zwar eine Problematik die mir bei der Verarbeitung von Logeinträgen mit Log2Syslog aufgefallen war, aber prinzipiell im Umfeld der Verwendung von SubProcess zu verallgemeinern ist.

Prinzipieller Sachverhalt aus meiner Sicht:

Ein Device eines Loghandlers (notify, Log2Syslog, ....) trägt sich im Hash %logInform ein, um zukünftig durch die sub Log3 über Änderungen im Logfile informiert zu werden und die Daten verarbeiten zu können.
Erfolgt dieser Eintrag jedoch erst nach dem Aufbau eines SubProcesses und einem dementsprechenden fork, fehlt der Eintrag im "geforkten" %logInform und auch der Hash des Loghandler-Devices im SubProcess.
In der Folge werden Log-Ausgaben, die im SubProcess über Log3 geschrieben werden, nicht an den Log-Handler weitergegeben und können durch das Log-Handler Device nicht verarbeitet werden.

Problematisch ist es dann, wenn der SubProcess gleich beim Start eröffnet wird und dann über die Laufzeit von FHEM genutzt und nicht wieder geschlossen wird was meiner Meinung nach der Sinn des Subprozesses ist, d.h. nicht ständiges Öffnen und Schließen.
DbLog arbeitet seit Jahresstart mit einem permanenten SubProcess und forkt auch unmittelbar nach Start von FHEM um nur wenig RAM zu verbrauchen. Andere Module betrifft es möglicherweise ebenfalls bzw. tragen sich vllt. weitere Modulautoren mit dem Gedanken SubProcess an Stelle von BlockingCall für bestimmte Abläufe einzusetzen.

Gesucht ist nun eine Lösung um einem SubProcess die Änderung von %logInform sowie die Hashes der Log-Handler (und deren evtl. Änderungen von DEF und Attributen) zu "spiegeln".
Die Lösung sollte meiner Meinung nach zentral über die fhem.pl verfügbar sein und durch Modulautoren genutzt werden können.


Grüße,
Heiko
 
 

[rudolfkoenig]

Das Problem hat nicht (nur) mit der Reihenfolge zu tun.
Kurz: in geforkten Prozessen (egal ob BlockingCall, SubProcess, etc) muss der Nutzer dieser Bibliotheken jeglichen Datenaustausch mit dem parent-Prozess explizit implementieren, eine Loesung ohne Datenaustausch funktioniert nur in Spezialfaellen.

Beispiel #1: Log2Syslog traegt sich vor DbLog in %log2inform ein, DbLog forkt spaeter. Falls Log2Syslog UDP fuer die Kommunikation mit dem Syslog Server verwendet, dann ist alles fein. Mit TCP aber halten zwei Prozesse jeweils einen gueltigen FileDescriptor fuer das eine Ende der TCP-Verbindung. Wenn die sich nicht synchronisieren, dann fuehrt das zu Problemen. Selbst das einfache Log3() kann zu einer korrupten Logdatei fuehren, weil die beiden Prozesse das Schreiben nicht synchronisieren.

Beispiel #2: der Benutzer will die DbLog Ausgaben im Event-Monitor sehen. Die mit DbLog geforkte FHEMWEB Instanz sieht aber keinen Auftrag vom Benutzer, dieser landet beim Parent.

Die Loesung ist die Logdaten zurueck zum parent-Prozess zu schicken, wie das in 98_update.pm gemacht wird: Log wird im geforkten Prozess auf update_Log2Event gebogen, was die Daten zum Parent schickt.

[DS_Starter]

Die Loesung ist die Logdaten zurueck zum parent-Prozess zu schicken, wie das in 98_update.pm gemacht wird: Log wird im geforkten Prozess auf update_Log2Event gebogen, was die Daten zum Parent schickt.

Das Verfahren werde ich mal implementieren. Danke Rudi.