Hi,
beim Testen meines Codes mittels meines selbst erstellten UnitTest Moduls bin ich vor einigen Wochen darauf umgestiegen die Ausführung der Tests mittels BlockingCall nichtblockierend zu praralellisieren.
Wenn der "geforkte" Prozess allerdings abschmiert, weil dort ein Fehler enthalten ist, so wird der Hauptprozess nicht so "richtig" informiert.
code]Undefined subroutine &SD_Protocols::checkProperty called at ./FHEM/00_SIGNALduino.pm line 2426
[/code]
Den BlockingCall Aufruf selbst gebe ich die finish und auch die aborted Funktion mit
BlockingCall("UnitTest_run", $hash, "UnitTest_finished", 300,"UnitTest_aborted");
Am Ende wird die finish Funktion aufgerufen, allerdings bekomme ich keine Logmeldungen aus dem Fork in mein Logfile. Hat das Problem schon mal jeder gelöst? Ich war der Meinung, man könnte aus einem geforkten Prozess auch Logmeldungen in FHEM erzeugen.
Grüße Sidey
Zitat von: Sidey am 30 April 2019, 15:53:03
Ich war der Meinung, man könnte aus einem geforkten Prozess auch Logmeldungen in FHEM erzeugen.
kann man und nutze ich auch bei meinen Modulen. Allerdings ist es mir auch schon passiert das durch einen hängenden Child zuerst keine Logeinträge kamen und nach einem kill waren sie dann doch da.
BTW Welchen 2 Parameter benutzt du bei Log3 xx , ? undef, $hash $name ?
Hi,
Danke für die Bestätigung.
Logomeldung ist z.B. folgende:
Log3 $name, 5, "$name: return from eval was with error $@" ;
Der geforkte Prozess hängt auch nicht wirklich
Den zu Testenden Code habe ich sogar extra in einen eval Block gesteckt.
Wenn ich darin einen Fehler habe, dann funktioniert aber außerhalb des eval auch nichts mehr.
Das ist schon sehr seltsam.
Wenn die finish Funktion aufgerufen wird, dann ist der geforkte Prozess beendet oder?
Grüße Sidey
Ich kann hier Entwarnung geben.
Das Logging funktioniert auch im Prozess der geforkte wird ich habe mir hier selbst eine Falle gestellt.