Hallo Zusammen,
habe heute meine FHEM-Installation geupdated (zuletzt am 23.06.).
Seit dem update landen alle STDOUT und STDERR Ausgaben im normalen Fhem-Logfile (verbose = 3).
Mein Fhem wird wie immer über den Befehl "perl fhem.pl fhem.cfg >>log/stdout.log 2>&1" gestartet, somit sollten diese eigentlich alle umgeleitet sein - was bisher auch einwandfrei funktionierte.
Hat jemand ne Idee / Tipp woran das liegt?
Gruß rapster
Ja, ich habe einen Bug gefixt.
Ich war naemlich seit 5 Jahren faelschlicherweise der Meinung, dass STDOUT/STDERR in fhem-log landet.
Code dafuer war vorhanden, es wurde aber bisher nur nach einem fhem-logfile Wechsel aufgerufen, typischerweise einmal im Monat, wenn bis dahin kein fhem-restart stattfand.
Hallo Rudolf,
alles klar - danke für die Info!
Gruß
Hallo,
aber es scheint, dass es mit der Umleitung doch noch Probleme gibt
https://forum.fhem.de/index.php/topic,63312.0.html
https://forum.fhem.de/index.php/topic,63139.0.html
Kurz: die STDOUT/STDERR Umleitung ist nicht perfekt, und man kann es nur mit Hilfe der gestarteten Prozesse richtig loesen.
Lang: Ich sehe zwei unabhaengige Probleme:
#1. jeder Prozess hat seinen eigenen Cache. Wenn Meldungen in der Datei synchron sein sollten, dann muss jeder nach jedem Schreibvorgang den Cache leeren, das fuehrt aber zu einem erhoehten Systemlast. Ausserdem kann man das bei externen Prozessen auch nicht beliebig einstellen.
#2. Wenn man Dateiwechsel bei STDOUT/STDERR fuer bereits gestartete Prozesse erzwingen will, dann muss man diese Daten erst wieder in FHEM einlesen (siehe man pipe / man dup), das bedeutet aber erneut erhoehte Systemlast. Und Problem #1 ist damit noch nicht geloest.
ZitatNormalerweise wird von mir alles aus dem Subprozess auf Stdout ausgegeben (mittels "print"). Deshalb auch die Log-Prozedur, die im Prinzip den Original Log-Mechanismus von Fhem nachbildet (da der Subprozess ja keinen Zugriff auf Fhem hat), bzw. im Falle des Modulteils der im Kontext von Fhem läuft das Original-Fhem-Log aufruft.
Wenn es wichtig ist, dass die Meldungen in der richtigen Reihenfolge, in der richtigen Datei landen, dann kann man sowas wie 98_update.pm machen: Da wird die Log Prozedur so umdefiniert, dass sie per telnet die Logmeldungen zum Vaterprozess schickt.
Siehe doUpdateInBackground bzw. update_Log2Event.
Ja, das verstehe ich ... aber: mir ist es egal in welche Log-Datei die Meldungen des Subprozesses gehen oder ob die zeitlich mit anderen Meldungen (genau) synchronisiert sind ...
Im Moment frage ich mich, wohin gehen die Subprozess (SONOS) Meldungen überhaupt ? Der Hauptprozess hat Filehandle für den 12-23 und 12-24 log offen, der Subprozess nur für den 12-23 log .. aber die Meldungen sind nirgendwo zu finden
Das kann ich leider nicht beantworten.
wo wird denn die Umleitung von STDOUT gemacht? Dann mache ich das testweise bei mir mal rückgängig ...
Das kriegt man mit "grep -r STDOUT /opt/fhem" aber auch raus.