Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern

DeeSPe · 03 März 2021, 09:57:59

Moin Dieter,

entschuldige bitte dass es nun doch nicht mehr so läuft wie gestern.
Ich hatte eine andere Stelle im Code gefunden wo es m.E. mehr Sinn machte die Abfrage einzubauen, das war offensichtlich falsch.
Nun habe ich es noch einmal angepasst, ich hoffe es passt nun wieder.
Es wäre nett wenn Du die angehängte Version noch einmal testen könntest.

Danke.

Gruß
Dan

EDIT: Anhang entfernt.

RockFan · 03 März 2021, 14:51:37

Hi Dan,

es tut mir leid berichten zu müssen, dass es mit der neuen Testversion auch nicht funktioniert

Viele Grüße
Dieter

DeeSPe · 03 März 2021, 17:16:06

Zitat von: RockFan am 03 März 2021, 14:51:37
Hi Dan,

es tut mir leid berichten zu müssen, dass es mit der neuen Testversion auch nicht funktioniert

Viele Grüße
Dieter

Ja klar, jetzt fällt mir auch auf warum es nicht geklappt hat.
Jetzt dürfte es wieder wie gewünscht funktionieren.
Bitte nochmal testen.

Danke und sorry für die Umstände.

Gruß
Dan

RockFan · 03 März 2021, 18:14:55

Yep, jetzt geht es wieder

Viele Grüße
Dieter

DeeSPe · 03 März 2021, 20:13:13

Zitat von: RockFan am 03 März 2021, 18:14:55
Yep, jetzt geht es wieder

Viele Grüße
Dieter

Danke für's Testen.
Habe ich dann diesmal genau so in SVN eingecheckt.

Gruß
Dan

RockFan · 04 März 2021, 10:30:52

Danke Dan!

Jetzt funktioniert auch die eingecheckte Version

Viele Grüße
Dieter

RockFan · 03 Mai 2021, 21:07:47

Hallo Dan,

ich muss mich leider nochmal mit einem Problem melden:
Das Attribut serviceStatusInterval steht bei mir auf 300, bei einem zweiten serviced-Device, das einen weiteren Service auf dem gleichen Raspi prüft auf 3600. Eigentlich lief das auch eine ganze Weile, bis mir aufgefallen ist, dass die Überprüfung buchstäblich stehen bleibt. D.h. es wurde für beide Dienste einfach kein Status mehr geprüft, bis ich dann jeweils einmalig bei beiden ein manuelles "get status" aufrief.

Vor einer Weile habe ich beide serviced-Devices auf verbose=5 gesetzt, um vielleicht etwas im Log zu finden. Dann lief es seltsamerweise bei beiden über viele Tage ohne Probleme. Als ich dann am Wochenende versehentlich den Sudo-Zugriff auf Linux-Ebene deaktiviert hatte und dann wieder neu erstellt habe, habe ich ein noch schlechteres Verhalten. Manuelle Status-Abfrage und auch ein Restart des Services (wozu ich ja sudo brauche) funktionieren. Aber die automatischen Statusabfragen alle 5 Minuten (bzw. alle 60 Minuten für den zweiten Dienst) gehen gar nicht mehr. Auch ein Neustart von FHEM hat auch nichts gebracht.

Ach ja, die Logausgabe mit verbose=5 ist nicht sehr ergiebig. Eigentlich bekomme ich nur das Folgende bei manueller Statusabfrage:

Code Auswählen


2021.05.03 06:30:18 5: tvheadend_service: serviced_Set executing shell command: ssh pi@medianas -p 22 'sudo service tvheadend status'
2021.05.03 06:30:19 5: tvheadend_service: serviced_ExecCmd com: ssh pi@medianas -p 22 'sudo service tvheadend status', line: 3
2021.05.03 06:30:19 4: tvheadend_service: Service "tvheadend" is started

Irgend eine Idee?

EDIT 4.5.2021:
Ich bin gerade auf die Idee gekommen einfach mal das Attribut serviceStatusInterval, das auf 300 gesetzt ist nochmal über attr zu speichern. Jetzt scheint wieder alle 5 Minuten ein Statuscheck zu laufen. Sehr seltsam.
Ich werde mal verbose=5 wieder rausnehmen und weiter beobachten. Ich befürchte, dass der Autocheck irgendwann wieder aufhört zu arbeiten.

Viele Grüße
Dieter

DeeSPe · 05 Mai 2021, 13:41:49

Hallo Dieter,

ich kann Deine bisherigen Beobachtungen teilen.
Hab mal kurz im Code nachgeschaut und glaube das Problem gefunden zu haben.
Mangels Testsystem kann ich das nur gerade nicht überprüfen.
Könntest Du evtl. die angehängte Version mal testen?
Es geht speziell darum zu testen ob der Status direkt nach dem FHEM Start abgerufen wird und im "serviceStatusInterval" wieder abgerufen wird.
Wenn es beim Start klappt, sollte es danach auch wieder klappen.

Gruß
Dan

P.S. Ich habe auch die commandref auf das neue Format umgestellt, somit sollten nun bei Auswahl der entsprechenden set/get/attr Dropdowns auch die Hilfetexte angezeigt werden.
P.P.S. Habe auch das Attribut "disableForIntervals" mit eingefügt.

RockFan · 05 Mai 2021, 19:16:05

Hallo Dan,

das Testergebnis mit der Testversion 1.2.8 ist leider negativ:
Beim Starten von FHEM und auch im Intervall erfolgt kein Statusabruf.
Erst wenn ich das Attribut, wie vorgestern, neu speichere geht es wieder: Status wird sofort und im definierten Intervall abgerufen.

Gib Bescheid, wenn ich noch etwas testen soll oder wenn du weitere Informationen brauchst.

Viele Grüße
Dieter

DeeSPe · 05 Mai 2021, 21:40:11

Danke für's Testen Dieter.
Nach erneutem Anschauen des Codes wird mir klar: das konnte nicht funktionieren!
Hier eine neue angehängte Testversion, ich hoffe diesmal klappt es wie gewünscht.

Gruß
Dan

RockFan · 05 Mai 2021, 23:17:31

Hi Dan,
ich muss Dich leider enttäuschen. Die neue Version verhält sich identisch.

Viele Grüße
Dieter

DeeSPe · 06 Mai 2021, 12:47:45

Danke nochmal für's Testen Dieter.
Ich war nun in der Lage es selbst mal zu testen und habe eine Lösung gefunden die nun wirklich funktionieren sollte, auch unter der Berücksichtigung des Attributs "serviceGetStatusOnInit".
Ist das Attribut "serviceGetStatusOnInit", so wird beim Start von FHEM einmalig der Status abgerufen, und falls auch "serviceStatusInterval" gesetzt ist startet nach dem ersten Statusabruf das Interval.
Ist nur "serviceStatusInterval" gesetzt, so wird (nach Neustart von FHEM) erst nach Ablauf des eingestellten Intervals der Status das erste Mal abgerufen und danach wieder im Interval.
Ab "verbose 4" ist das auch im Log zu sehen mit "$name: automatic start of status interval (XXXsec)".

Bitte gerne testen.
Danke.

Gruß
Dan

Gisbert · 06 Mai 2021, 15:56:04

Hallo Dan,

ich glaube, weiß es aber nicht 100%ig, dass ich dieses Modul auch nutze. Ist das angehängte Modul nur testweise angehängt, und ansonsten läuft das Update über den Fhem-Update-Prozess?

Viele Grüße Gisbert

DeeSPe · 06 Mai 2021, 16:01:31

Zitat von: Gisbert am 06 Mai 2021, 15:56:04
Hallo Dan,

ich glaube, weiß es aber nicht 100%ig, dass ich dieses Modul auch nutze. Ist das angehängte Modul nur testweise angehängt, und ansonsten läuft das Update über den Fhem-Update-Prozess?

Viele Grüße Gisbert

Hallo Gisbert,

hierbei handelt es sich nur um eine Testversion um das Problem zu fixen.
Sobald ich das "okay" auch vom Tester (RockFan) bekomme dass es nun wie gewünscht funktioniert, werde ich das natürlich wieder in's SVN einchecken damit es dann über den regulären Updateprozess mit verteilt wird.

Gruß
Dan

RockFan · 06 Mai 2021, 19:49:29

Hallo Dan,

das Verhalten hat sich jedenfalls geändert:
Beim Starten wird jetzt der Status ermittelt. Im Log mit verbose=5 finde ich folgende Einträge:

Code Auswählen


2021.05.06 19:30:04 3: tvheadend_service: get status of service "tvheadend" due to startup
2021.05.06 19:30:04 5: tvheadend_service: serviced_Set executing shell command: ssh pi@medianas -p 22 'sudo service tvheadend status'

serviceGetStatusOnInit ist auf 1 gesetzt.

Leider passiert aber nach 5 Minuten (Intervall ist auf 300 gesetzt) nichts (auch nach 10 Minuten ist nichts).
Ein manuelles Setzen des Intervall-Attributes bringt es wie gehabt wieder in Gang.

Ich habe ja noch einen zweiten Service. Bei dem ist serviceGetStatusOnInit ist auf 0 und das Intervall auf 3600 gesetzt.
Hier steht im Log

Code Auswählen


2021.05.06 19:30:04 4: telerising_service: automatic start of status interval (3600sec)

und der Status wird beim Starten nicht geprüft. Das ist laut Deiner Beschreibung auch richtig.
Mal sehen was hier nach einer Stunde passiert ist....

Sobald ich dann am PC vorbeikomme berichte ich.

EDIT 1:
Nach einer Stunde hat der zweite Service den Status geprüft. Ob das auch nur einmalig ist, werde ich nach einer weiteren Stunde sehen ...

EDIT 2:
Nach einer weiteren Stunde wurde beim zweiten Service wieder geprüft. Da hängt es also bisher nicht. Ich werde weiter beobachten ...

Viele Grüße
Dieter