Blocking Call by Server shutdown

[SCMP77]

Hallo,

ich habe in meiner Log-Datei bei manchen Shutdowns folgende Log-Einträge:

Code Auswählen Erweitern

2016.02.14 01:00:19 0: Server shutdown
2016.02.14 01:00:20 1: BlockingInformParent (SolvisMax_Finish): Can't connect to localhost:7072: IO::Socket::INET: connect: Interrupted system call

Hierbei handelt es sich um keinen Restart!

Ich habe hierzu in der BlockingCall-Doku folgendes gefunden:

Verwenden einer UndefFn um laufende BlockingCalls zu beenden

Wenn gerade ein BlockingCall läuft und man will FHEM herunterfahren oder neustarten kann das problematisch werden, da ja immer noch Unterprozesse laufen und so einen kompletten Stop verhindern können.

Daher muss in der UndefFn des Moduls sichergestellt werden, dass ein laufender BlockingCall beendet wird. Dazu wird als Argument der Return-Hash von BlockingCall benötigt in dem unter anderem die PID des Unterprozesses enthalten ist. Die Funktion BlockingKill() erledigt dann den Rest.

Das habe ich in mein Modul eingebaut und trotzdem kommt die obige Fehlermeldung.

Ich habe daraufhin mir fhem.pl angesehen und es schein so, dass bei einen reinen Shutdown die "UndefFn" eines Moduls nicht aufgerufen wird. Stattdessen wird versucht eine "ShutdownFn"-Funktion aufzurufen.

Man müsste also - um dieses mehr oder weniger kosmetische Problem zu verhindern - den BlockingKill auch in dieser "ShutdownFn"-Funktion realisieren.

Kann das jemand bestätigen?

Ist die "ShutdownFn" dafür eine offizielle Methode oder besteht die Gefahr, dass das wieder ausgebaut wird, weil es wohl bisher nicht dokumentiert wurde oder sollte man besser das  global:SHUTDOWN-Ereignis nutzen?

Gruß
    SCMP77

[rudolfkoenig]

Wg. UndefFn: ich bin der Ansicht, dass die Doku hier falsch ist: ShutdownFn wird beim Shutdown aufgerufen, UndefFn beim Delete und beim rereadcfg (btw, rereadcfg sollte mAn ShutdownFn und nicht UndefFn aufrufen, ist aber historisch bedingt).

Dass der (fehlende) Aufruf dieser Funktionen mit der erwaehnten Fehlermeldung zu tun hat, wage ich zu bezweifeln:
- offensichtlich dauert connect etwas laenger.
- in dieser Zeit bekommt der Kind-Prozess ein Signal, was nicht ignoriert wurde, deswegen wird connect unterbrochen.

Um das Problem zu klaeren braucht man viel mehr Info:
- auf welchem OS tritt es auf
- was macht (grob) dieser Prozess, ich denke an alles, was Signale sendet, wie Programme starten, etc.
- wann tritt die Meldung auf: nach einem rereadcfg/shutdown restart oder im normalen Betrieb?

[SCMP77]

Hallo,
vielen Dank für die Antwort.

(btw, rereadcfg sollte mAn ShutdownFn und nicht UndefFn aufrufen, ist aber historisch bedingt).

Das hatte ich jetzt auch festgestellt. Eigentlich hatte ich vor in Undef mit setKeyValue Einträge aus der Restart-Festen-Datei zu entfernen. Da aber gerade bei einem Restart Undef aufgerufen wird, kann ich das so nicht machen. Die Einträge müssen wohl oder Übel drin bleiben oder gibt es da noch eine weitere Möglichkeit, sprich kann ich erkennen, dass ein undef durch den restart ausgelöst wurde?

Um das Problem zu klaeren braucht man viel mehr Info:
- auf welchem OS tritt es auf

Auf dem Raspberry Pi Modell B unter Arch-Linux

- was macht (grob) dieser Prozess, ich denke an alles, was Signale sendet, wie Programme starten, etc.

Er führt einen HTTP-Abfrage aus, die dann eine XML-Antwort erwartet. Eine Zeile aus den empfangenen XML-Daten ist dann auch die Rückgabedaten des Kind-Prozesses. Die eigentliche Auswertung der XML-Daten erfolgt nicht mehr im Kind-Prozess, da hier Readings gesetzt werden müssen. Die Dauer der eigentlichen Abfrage  bzw. die Laufzeit des Kind-Prozesses liegt so bei etwa bei 0,3 bis max. 1s (schwankt immer etwas).

- - wann tritt die Meldung auf: nach einem rereadcfg/shutdown restart oder im normalen Betrieb?

Bei einem Betriebssystem-Shutdown ( shutdown -P now)

Gruß
    SCMP77

[rudolfkoenig]

Bei einem Betriebssystem-Shutdown ( shutdown -P now)

Da shutdown vermutlich ein SIGTERM versendet, koennte man einen lokalen Handler aufsetzen, und den Prozess beenden.
Ist eine Fehlermeldung im Fhem-Log beim shutdown tragisch?

[SCMP77]

Hallo,

Ist eine Fehlermeldung im Fhem-Log beim shutdown tragisch?

Sicherlich nicht. Ich persönlich versuche nur immer solche Meldungen auf den Grund zu gehen, weil sich da vielleicht ein größeres Problem hinter verbergen könnte. So ist die Fehlermeldung aber nur ein kosmetisches Problem, was die Funktion wohl nicht stören dürfte.

Vielen Dank
    SCMP77