Presence "vergisst" lan-ping Überwachung

[Mattias]

Im Rahmen meines anderen Beitrags bin ich auf ein weiteres Problem in Presence bzw. Blocking gestossen.

Presence verwendet BlockingCall aus Blocking.pm für die "asynchrone" Ausführung von Ping. Dabei wird ein Timeout von 20 Sekunden vorgegeben. Falls der Timeout erreicht wird, ohne das der Befehl (hier also Ping) beendet wurde, wird ein interner Timer getriggert und der Befehl terminiert (BlockingKill). Auf meiner Fritzbox benötigt der von presence verwendete Ping-Befehl 14 Sekunden, wenn die überwachte IP-Adresse nicht erreichbar ist. Wenn die Fritzbox sehr beschäftigt ist, zB wegen tar und zip eine hohe load hat, reichen die 20 Sekunden nicht und BlockingKill beendet den Ping Befehl. Die "Rendezvous-Funktion" PRESENCE_ProcessLocalScan(), bei BlockingCall als $finishFn bezeichnet, wird in diesem Fall nicht aufgerufen.
Das hat zur Folge, dass der Timer, der die nächste lan-ping Ausführung triggern soll, nicht neu gestartet wird, ergo die komplette Überwachung für diese Presence-Definition zum Erliegen kommt.

Im fhem.log lässt sich das Problem an folgenden Meldungen erkennen:

Code Auswählen Erweitern

2013.03.19 17:38:05 1: Terminated 10783
2013.03.19 19:14:40 1: Terminated 12180
2013.03.19 19:15:24 1: Terminated 12220
2013.03.19 19:16:01 1: Terminated 12244
2013.03.19 19:20:06 1: Terminated 12424
2013.03.19 19:24:23 1: Terminated 12704
2013.03.19 19:56:16 1: Terminated 12984(Nebenbei: Für Loglevel 1 finde ich die BlockingKill-Ausgabe eher karg, da sich für den Anwender nicht erkennen lässt welches Kommando gerade gekillt wurde. Die Ausgabe des gerade zwangsterminierten Kommandos würde sicher bei der weiteren Analyse sicher helfen, falls das Problem - wie meistens - unerwartet auftritt)

Vorschlag: BlockingCall um einen (optionalen) Parameter erweitert werden sollte. Diese "OnTimeout"-Funktion sollte im Timeout-Fall, nach dem Kill des Befehls, aufgerufen werden. Presence könnte so sicherstellen, dass die Überprüfung fortgesetzt wird oder eine verständliche Logmeldung ausgeben. Falls das zu kompliziert ist, muss presence das Neustarten des Timers von dem Beenden des Befehls entkoppeln.

(Apropos: Wenn ich als Intervall 60 angebe und Ping 14 Sekunden benötigt, dann wird faktisch alle 74 Sekunden geprüft, oder?)

[Markus Bloch]

Vorschlag: BlockingCall um einen (optionalen) Parameter erweitert werden sollte. Diese "OnTimeout"-Funktion sollte im Timeout-Fall, nach dem Kill des Befehls, aufgerufen werden. Presence könnte so sicherstellen, dass die Überprüfung fortgesetzt wird oder eine verständliche Logmeldung ausgeben. Falls das zu kompliziert ist, muss presence das Neustarten des Timers von dem Beenden des Befehls entkoppeln.

Den Vorschlag werde ich mitnehmen. Da mir aktuell die Zeit fehlt, denke ich, dass ich das ganze evtl. nächste Woche durchführen kann. Als Workaround habe ich erstmal den Timeout von 20 auf 60 Sekunden erhöht.

(Apropos: Wenn ich als Intervall 60 angebe und Ping 14 Sekunden benötigt, dann wird faktisch alle 74 Sekunden geprüft, oder?)

Ja das ist richtig. Hintergrund ist hier sicherzustellen, dass ein Thread beendet wurde, bevor der nächste Thread gescheduled wird. Damit soll vermieden werden, dass Threads gestartet werden, bevor der vorherige beendet ist und sich damit hochschaukeln könnten.

Viele Grüße

Markus

[Markus Bloch]

Hi Mattias,

Rudolf hat mir soeben die Grundlagen gelegt. Die restliche Umsetzung in Presence werde ich in den Osterwochen evtl. angehen.

Ich sag dir bescheid.

Viele Grüße

Markus

[Markus Bloch]

Hallo Mattias,

das Problem habe ich soeben gefixet. Ist ab morgen via update verfügbar.

Viele Grüße

Markus