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

[DeeSPe]

Das ist wieder typisch!
Die einzige Konstellation die ich nicht direkt getestet hatte funktioniert natürlich wieder nicht.
Aber eigentlich war mir das vorhin beim Code Review schon fast klar, ich hatte es nur nicht geändert weil ich dachte eventuell doch etwas damit kaputt zu machen.
Nun habe ich, denke ich, die beste Lösung gefunden.
Sobald "serviceGetStatusOnInit" und/oder "serviceStatusInterval" gesetzt ist, wird beim Start von FHEM nun der Status abgerufen. Ab "verbose 4" kommt dann im Log:

Code Auswählen Erweitern

$name: get status of service {SERVICENAME} due to startup and/or interval
Und wenn "serviceStatusInterval" gesetzt ist wird dann das entsprechende Interval wieder ausgeführt.

Bitte nochmal testen ob es nun wie gewünscht funktioniert.

Gruß
Dan

[RockFan]

Hallo Dan,

jetzt sieht es gut aus 
Beide Services haben nach dem FHEM-Start aktualisiert und der erste Service dann wieder nach 5 Minuten, also so, wie es sein soll.

Danke für die Korrekturen.

Gute Nacht!

Dieter

[DeeSPe]

Danke nochmal für's Testen!
Schön dass es nun klappt wie gewünscht.
Ich checke die Version dann ins SVN ein und sie ist dann ab morgen früh im Update erhältlich.

Gruß
Dan

[RockFan]

Danke fürs Fixen 

Habe heute Abend ein FHEM-Update gefahren und werde nun über einen längeren Zeitraum beobachten, ob es noch zu Hängern kommt.

Viele Grüße
Dieter

[taskkill]

Guten Tag, ist es auch irgendwie möglich alle Dienste vom Rpi automatisch erfassen zu lassen und nur den Status anzuzeigen ?

[DeeSPe]

Guten Tag, ist es auch irgendwie möglich alle Dienste vom Rpi automatisch erfassen zu lassen und nur den Status anzuzeigen ?

Nein.

Gruß
Dan

[JensS]

Das hat jetzt nichts mit dem Modul zu tun aber die Dienste, welche in systemd hinterlegt sind, kannst du auch auf Linuxebene mit "systemctl list-units" abfragen. Achtung: für die Dauer der Abfrage ist FHEM blockiert! Hier mal ein Beipiel-at auf ein servicedummy-Device:

Code Auswählen Erweitern

defmod ServiceStatus_at at +*00:01:00 {\
my $linuxreturn = qx(systemctl list-units | grep .service);;\
my @Services = split(/\n/,$linuxreturn);;\
foreach (@Services){\
my @ServiceReading = split(/ +/,$_,6);;\
fhem("setreading servicedummy $ServiceReading[1] $ServiceReading[4]")};;\
}


Gruß Jens

[Wernieman]

Deshalb doch besser in ein externes Script auslagern und das "Non-Blocking" aufrufen?
Mußt Dir dann nur überlegen, wie Du die Daten in FHEM bekommst (telnet, Web, MQTT o.Ä.)

[Elektrolurch]

Hallo,

habe mein debian System (AMD) nun auf bullseye aktualisiert und habe jetzt mit dem serviced - Modul Probleme (Auszug aus log/fhem-04-29.log nach der Abfrage des status eines laufenden Dienstes über das entsprechende serviced - Objekt):

Code Auswählen Erweitern


sudo: Ein Passwort ist notwendig
sudo: Zum Lesen des Passworts ist ein Terminal erforderlich; verwenden Sie entweder die Option -S, um aus der Standardeingabe zu lesen oder richten Sie das Askpass-Hilfsprogramm ein
sudo: Ein Passwort ist notwendig


In der /etc/sudoers steht folgendes:

Code Auswählen Erweitern


# Cmnd alias specification
Cmnd_Alias FHEM_CMDS = /bin/systemctl *, /usr/sbin/service *
...

fhem ALL=(ALL:ALL) NOPASSWD: FHEM_CMDS

Gibt man in ein TTerminal als user fhem folgendes ein, so kommt:

Code Auswählen Erweitern


fhem@Speicherknecht:/media/public$ systemctl restart dnsmasq
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Legitimierung ist zum Neustarten von »dnsmasq.service« notwendig.
Authenticating as: Elektrolurch Müller,,, (Elektrolurch)
Password:


Sieht jemand, was da nicht stimmt?
Warum werden die Anweisungen in der /etc/sudoers anscheinend ignoriert?

Merkwürdig ist, dass es bis vor dem update funktionierte.
Ein zeites System mit ARM und debian bullseye funktioniert weiterhin mit den gleichen Anweisungen in der /etc/sudoers

Interne Daten von dnsmasq:

Code Auswählen Erweitern


DEF
dnsmasq
FUUID
606ad19e-f33f-c8c3-d89f-7beee8fcb1f32b75
NAME
dnsmasq
NOTIFYDEV
global
NR
882
NTFY_ORDER
50-dnsmasq
SERVICENAME
dnsmasq
STATE
error
TYPE
serviced
VERSION
1.2.8
Readings
error
sudo: Zum Lesen des Passworts ist ein Terminal erforderlich; verwenden Sie entweder die Option -S, um aus der Standardeingabe zu lesen oder richten Sie das Askpass-Hilfsprogramm ein sudo: Ein Passwort ist notwendig
2022-04-29 13:03:53
state
error
2022-04-29 13:03:53
status
Active: active (running) since Thu 2022-04-28 23:59:14 CEST; 63ms ago
2022-04-28 23:59:14
attr
dnsmasq
room

Attributes
alias
dns
deleteattr
cmdIcon
restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY
deleteattr
devStateIcon
Initialized|status:light_question error|failed:light_exclamation running:audio_play:stop stopped:audio_stop:start stopping:audio_stop .*starting:audio_repeat
deleteattr
genericDeviceType
switch
deleteattr
homebridgeMapping
On=state,valueOff=/stopped|failed/,cmdOff=stop,cmdOn=start StatusJammed=state,values=/error|failed/:JAMMED;/.*/:NOT_JAMMED
deleteattr
icon
hue_room_garage
deleteattr
serviceInitd
1
deleteattr
webCmd
start:restart:stop:status
deleteattr




Elektrolourch

[Wernieman]

1, Arbeite besser mit /etc/sudoers.d/<toller Dateiname>  und lass die Original sudoers in Ruhe
2. Wie bearbeitest Du die sudoers?

[Elektrolurch]

DAnke für den Tippp:

1. Editieren mit Syntaxcheck, wie üblich
2. Auslagerung der zwei Zeilen für fhem in eine eigene Datei in das dir sudoers.d hat nichts geändert.
3. Syntax von sudoers schein ok zu sein.

Code Auswählen Erweitern


fhem@Speicherknecht:/media/public$ systemctl restart dnsmasq
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Legitimierung ist zum Neustarten von »dnsmasq.service« notwendig.

Das scheint das Problem zu sein: "FOR org.freedesktop.systemd1.manage-units ".
Woher kommt das und wieso ist es anscheind auf der anderen Installation kein Problem?
Das Modul "serviced" ruft ja den selben Befehl auf....

Elektrolurch

[Wernieman]

Kannst Du bitte prüfen:
1. Stimmt der Pfad?
z.B. mit "whereis  systemctl"
Bei mir spuckt er einen anderen Pfad auf, allerdings aktuell auch kein RasPi

2. Wenn Du alles nach dem "," Weg lässt, also nur systemctl drin steht, wie sieht es dann aus?

3. Wenn Du das "*" weg lässt.....

[Elektrolurch]

Hallo,

1. der Pfad hatte sich tatsächlich von buulseye ARM /binsystemctl auf bullseye AMD geändert in /usr/bin/systemctl.
Habe das angepasst und  auch nach einem Neustart des systems funktioniert es immer noch NICHT.
2. Auch das habe ich ausprobiert, nur eine Anweisung und auch ohne *
Geht leider auch nicht.

Als angemeldeter user 'fhem' kommt immer über die Kommandozeile bei dem AMD - System:

Code Auswählen Erweitern


fhem@Speicherknecht:/media/public$ /usr/bin/systemctl restart dnsmasq
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Legitimierung ist zum Neustarten von »dnsmasq.service« notwendig.

Gebe ich dann das Passwort für den Nutzer 'Elektrolurch' (nicht fhem!!!!) ein, wird der Befehl ausgeführt.
Auf dem ARM-System funktioniert es ohne Rückfrage und Passwort Eingabe, wie es bei der Anweisung NOPASSWD in der sudoers - Datei auch zu erwarten wäre.
Was ist das überhaupt für ein Dienst (AUTHENTICATING FOR org.freedesktop.systemd1...), der diese Meldung erzeugt.
Auf dem ARM habe ich so etwas noch nicht gesehen.

Elektrolurch

[Wernieman]

Wenn Du schon sudo willst, warum rufst Du systemctl dann ohne sudo auf?

Richtig also:

Code Auswählen Erweitern

sudo /usr/bin/systemctl restart dnsmasq

[Elektrolurch]

Sorry, habe ich dann auch gemerkt:

Code Auswählen Erweitern


sudo /usr/bin/systemctl restart dnsmasq


Als eingeloggter user fhem kommt die Mitteilung jetzt auch nicht mehr.
Aber über das serviced - Modul geht es lokal immer noch nicht....
Ob da vielleicht der andere Pfad zu der "systemctl eine Rolle spielt?
Die Meldungen kommen übrigens aus dem "policy kit" (polkit) Modul, was anscheinend erst mit bullseye dazu gekommen ist.
siehe hierzu auch die Erklärungen unter:
https://unix.stackexchange.com/questions/650826/why-is-this-error-interactive-authentication-required-popping-up
Eigentlich steht da auch, dass ein Eintrag in der sudoers mit NOPASSWD ausreichend sein sollte.

Und eine mögliche Lösung mit dem polkit (ohne Eintrag NOPASWWD in der sudoers) :
https://unix.stackexchange.com/questions/606452/allowing-user-to-run-systemctl-systemd-services-without-password/606476#606476

Warum geht das starten / stoppen von Diensten über das Modul serviced remote auf der ARM - maschine?
Weil der service "polkit" nicht startet.
An der eingetragene Stelle für den Dienst fehlt das binary....
/lib/systemd/system/polkit.service:

Code Auswählen Erweitern


[Unit]
Description=Authorization Manager
Documentation=man:polkit(8)

[Service]
Type=dbus
BusName=org.freedesktop.PolicyKit1
ExecStart=/usr/lib/policykit-1/polkitd --no-debug

Da gibt es nur eine Datei: polkit-agent-helper-1


Elektrolurch