FHEM Forum

FHEM - Hausautomations-Systeme => Unterstützende Dienste => Thema gestartet von: DeeSPe am 22 November 2017, 01:03:15

Titel: Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 22 November 2017, 01:03:15
Das Modul wird mit dem FHEM Updateprozesses ausgeliefert!

Mit serviced können lokale und entfernte Dienste verwaltet werden.
Die üblichen Kommandos sind verfügbar: start/restart/stop/status.
Der Status kann auch in definierbarem Interval aktualisiert werden.

Define

define <name> serviced <Dienst Name> [<user@ip-adresse>]

Beispiel serviced für lokale Dienste:

define hb serviced homebridge

Beispiel serviced für entfernte Dienste:

define hyp serviced hyperion pi@192.168.1.4

Für entfernte Dienste muss dem Benutzer unter dem FHEM läuft dass passwortlose Anmelden per SSH erlaubt werden. Eine Anleitung wie das zu machen geht ist unter diesem Link (http://www.linuxproblem.org/art_9.html) abrufbar.

Zur Benutzung von systemctl (systemd) oder service (initd) müssen dem Benutzer unter dem FHEM läuft die entsprechenden Rechte in der sudoers Datei erteilt werden (/etc/sudoers) (visudo).
Die sudo Rechte können auch gezielter als hier gezeigt spezifiziert werden, dazu bitte mit sudoers vertraut machen.
Nähere Infos auch in Beitrag #49 (https://forum.fhem.de/index.php/topic,79952.msg722361.html#msg722361).

Für systemd (bitte mit eigenen Pfaden abgleichen):
fhem ALL=(ALL) NOPASSWD:/bin/systemctl

Für initd (bitte mit eigenen Pfaden abgleichen):
fhem ALL=(ALL) NOPASSWD:/usr/sbin/service



Set

start
angehaltenen Dienst starten

stop
laufenden Dienst anhalten

restart
Dienst neu starten

status
Status des Dienstes abrufen



Get

status
Status des Dienstes abrufen
identisch zu 'set status'



Attribute

disable
Anhalten der automatischen Abfrage und komplett deaktivieren
Voreinstellung: 0

serviceAutostart
Verzögerung in Sekunden um den Dienst nach Start von FHEM (neu) zu starten
Voreinstellung:

serviceAutostop
Timeout in Sekunden um den Dienst bei Beenden von FHEM ebenso zu beenden
Voreinstellung:

serviceGetStatusOnInit
beim Start von FHEM automatisch den Status des Dienstes abrufen
Voreinstellung: 1

serviceInitd
benutze initd (system) statt systemd (systemctl)
Voreinstellung: 0

serviceLogin
SSH Anmeldedaten für entfernten Dienst
passwortloser SSH Zugang ist Grundvoraussetzung
Voreinstellung:

serviceRegexFailed
Regex für failed Status
Voreinstellung: dead|failed|exited

serviceRegexStarted
Regex für running Status
Voreinstellung: running|active

serviceRegexStarting
Regex für starting Status
Voreinstellung: activating|starting

serviceRegexStopped
Regex für stopped Status
Voreinstellung: inactive|stopped

serviceStatusInterval
Interval um den Status automatisch zu aktualisieren
Voreinstellung:

serviceStatusLine
Zeilennummer der Status Rückgabe welche die Status Information enthält
Voreinstellung: 3

serviceSudo
sudo benutzen - bei Benutzer root wird automatisch kein sudo verwendet
Voreinstellung: 1



Readings

error
letzter aufgetretener Fehler

state
aktueller Zustand

status
letzte Statuszeile von 'get/set status'




Die commandref ist genau so in EN/DE enthalten.

Tester und Kommentare sind willkommen.
Viel Spaß damit.

Gruß
Dan

UPDATE: 24.11.
- error mit none überschreiben wenn keine Fehler mehr vorliegen
- Attribute homebridgeMapping und genericDeviceType werden nur noch gesetzt wenn das Attribut homebridgeMapping vorhanden ist
- weitere Verbesserungen

UPDATE2: 24.11.
- fix Attribute RegEx Prüfung
- dead|failed|exited als Default für serviceRegexFailed

UPDATE 26.11.: v1.2.1
- neues Attribut serviceAutostart um Dienste beim Start von FHEM automatisch mit dem hier eingestellten Wert in Sekunden verzögert zu starten
- neues Attribut serviceAutostop um Dienste beim Beenden von FHEM automatisch zu beenden mit dem hier eingestellten Timeout
- AbortFn für BlockingCall hinzugefügt

UPDATE 27.11.: v1.2.3
- serviceAutostop funktioniert nun wie erwartet
- neues Attribut serviceGetStatusOnInit um den Status des Dienstes beim Start von FHEM automatisch zu aktualisieren (default: 1)
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: KlaGho am 22 November 2017, 13:28:09
Funktioniert bei mir gut.
Ich hatte vorher Deine manuelle Version über UserReadings (auch die funktionierte sehr gut)

Gruß gho
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: binford6000 am 22 November 2017, 22:22:35
Coole Sache. Funktioniert out-of-the-box!
VG Sebastian
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: igami am 23 November 2017, 06:20:47
Da hat sich jemand an meinen Wunsch erinnert :) https://forum.fhem.de/index.php/topic,40127.0.html?PHPSESSID=i448rubf72kfv6fhovik4n52h5
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Steffen@Home am 23 November 2017, 07:15:55
Morgen Dan,

steh ich auf dem Schlauch oder warum finde ich weder in der Commandref noch in fhem wiki was zu "serviced" ?  ???

Gruß Steffen
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Amenophis86 am 23 November 2017, 07:20:15
Weil es noch nicht eingecheckt ist und daher hier als Download zur Verfügung steht.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 23 November 2017, 10:43:36
Zitat von: igami am 23 November 2017, 06:20:47
Da hat sich jemand an meinen Wunsch erinnert :) https://forum.fhem.de/index.php/topic,40127.0.html

Den Wunsch kannte ich nicht und zur Zeit des Wunsches kannte ich auch FHEM noch nicht. ;)

Zitat von: Steffen@Home am 23 November 2017, 07:15:55
steh ich auf dem Schlauch oder warum finde ich weder in der Commandref noch in fhem wiki was zu "serviced" ?  ???

Wie Amenophis86 schon geschrieben hat ist das eine Vorab-Version.
Ich möchte damit primär sehen ob überhaupt Interesse an diesem Modul besteht.
Evtl. funktioniert auch irgendwas (noch) nicht richtig bei anderen Betriebssystemen, auch das soll hierbei zu Tage kommen.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Amenophis86 am 23 November 2017, 11:05:47
Ich habe übrigens auch Interesse dran, muss nur schaue wann ich zum Testen komme. Also bitte nicht zu früh die Flinte ins Korn werfen :)
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Esjay am 23 November 2017, 12:23:38
Zitat von: igami am 23 November 2017, 06:20:47
Da hat sich jemand an meinen Wunsch erinnert :) https://forum.fhem.de/index.php/topic,40127.0.html?PHPSESSID=i448rubf72kfv6fhovik4n52h5

Zitat von: Esjay am 02 Dezember 2016, 22:12:43
Hi DeeSPe,

wäre es möglich,einen set Befehl einzubauen, welcher der Hardware (z.B seperater Raspberry) auf der Hyperion läuft nen shutdown Befehl verpasst? Ich weiß,dass dafür der Austausch der Keys ect. nötig ist, und ich denke auch drüber nach, ob es Sinn macht das in diesem Modul aufzunehmen, aber da ich gerne alles unter einem Dach habe, dachte ich, dass ich mal nachfrage.

Habt ihr eure Hyperion Hardware immer am Netz? Ich würde es gern bei Bedarf über eine Funksteckdose zuschalten. Nur wird auf dauer die SD Karte darunter leiden.

Ansonsten wahnsinn, welchen Umfang das Modul mittlerweile hat.

Grüße
Zitat von: DeeSPe am 23 November 2017, 10:43:36
Den Wunsch kannte ich nicht und zur Zeit des Wunsches kannte ich auch FHEM noch nicht. ;)
..................

Ich nehme es gerne auf meine Kappe  ;D ;)

Bin auch gerade  wieder an dem Thema dran. Hab es bisher nur nicht geschafft, den Passwortlosen Zugriff auf meinem Zyxel 325 einzurichten. Bis dahin werd ich das Ganze mal an meinem Hyperion Server ausprobieren.

Grüße
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 23 November 2017, 14:17:37
Ich habe noch vergessen zu erwähnen dass das Abfragen der Dienste natürlich nicht blockierend ist.
Immer Fehlerfalle wird auch die Fehlermeldung im Reading error ausgegeben.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Cobra am 23 November 2017, 16:11:04
Hallo zusammen,

ich versuch mich auch gerade dran, scheitere aber irgendwie an den Rechten. Muss auch gestehen dass ich nicht der Linux-Profi bin.

Ich habe sowohl Homebridge als auch Alexa auf nem eigenen Raspberry laufen auf dem kein FHEM installiert ist.
Demnach dachte ich es reicht aus die Anleitung für den SSH Login mit dem Nutzer PI zu machen.

Nun kommt aber als Fehlermeldung immer

Permission denied please try again. Permission denied please try again. Permission denied (publickeypassword).

Hier mal das List von Alexa-Service:

Internals:
   CFGFN
   DEF        alexa pi@192.168.178.9
   NAME       Alexa_Service
   NOTIFYDEV  global
   NR         1046
   NTFY_ORDER 50-Alexa_Service
   SERVICENAME alexa
   STATE      error
   TYPE       serviced
   READINGS:
     2017-11-23 16:05:11   error           Permission denied please try again.  Permission denied please try again.  Permission denied (publickeypassword).
     2017-11-23 16:05:11   state           error
   helper:
Attributes:
   alias      Service alexa
   cmdIcon    restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY
   devStateIcon Initialized|status:light_question error|failed:light_exclamation running:audio_play:stop stopped:audio_stop:start stopping:audio_stop .*starting:audio_repeat
   genericDeviceType switch
   homebridgeMapping On=state,valueOff=/stopped|failed/,cmdOff=stop,cmdOn=start
StatusJammed=state,values=/error|failed/:JAMMED;/.*/:NOT_JAMMED
   icon       hue_room_garage
   room       Services
   serviceLogin pi@192.168.178.9
   webCmd     start:restart:stop:status


Hier die Statusmeldung vom Alexa-Service direkt auf dem PI:

pi@raspberrypiwz:~ $ sudo service alexa status
● alexa.service - Node.js Alexa Server
   Loaded: loaded (/etc/systemd/system/alexa.service; enabled)
   Active: active (running) since Thu 2017-11-23 16:01:55 CET; 5min ago
Main PID: 711 (alexa)
   CGroup: /system.slice/alexa.service
           └─711 alexa

Nov 23 16:02:02 raspberrypiwz alexa[711]: [11/23/2017, 4:02:02 PM] [FHEM] { ...,
Nov 23 16:02:02 raspberrypiwz alexa[711]: cmd: 'desired-temp',
Nov 23 16:02:02 raspberrypiwz alexa[711]: delay: true,
Nov 23 16:02:02 raspberrypiwz alexa[711]: minValue: 5,
Nov 23 16:02:02 raspberrypiwz alexa[711]: maxValue: 30,
Nov 23 16:02:02 raspberrypiwz alexa[711]: minStep: 0.5,
Nov 23 16:02:02 raspberrypiwz alexa[711]: device: 'WT.Schlafzimmer_Climate',
Nov 23 16:02:02 raspberrypiwz alexa[711]: informId: 'WT.Schlafzimmer_Climate...,
Nov 23 16:04:00 raspberrypiwz alexa[711]: 2017-11-23 16:04:00 caching: WT.Wo...7
Nov 23 16:04:01 raspberrypiwz alexa[711]: 2017-11-23 16:04:01 caching: WT.Sc...6
Hint: Some lines were ellipsized, use -l to show in full.


In /etc/sudoers (auf dem PI auf dem Alexa und Homebridge läuft) habe ich folgende Einträge gemacht:

fhem ALL=(ALL) NOPASSWD:/etc/init.d
pi ALL=(ALL) NOPASSWD:/etc/init.d
pi ALL=(ALL) NOPASSWD:/etc/systemd/system/
fhem ALL=(ALL) NOPASSWD:/etc/systemd/system/


Hab ich noch irgend etwas übersehen was gemacht werden muss?

Gruß Cobra
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: mahowi am 23 November 2017, 16:21:44
/etc/init.d und /etc/systemd/system/ sind Verzeichnisse.

Aus dem ersten Post:
Zitat von: DeeSPe am 22 November 2017, 01:03:15
Zur Benutzung von systemctl (systemd) oder service (initd) müssen dem Benutzer unter dem FHEM läuft die entsprechenden Rechte in der sudoers Datei erteilt werden (/etc/sudoers) (visudo).

Für systemd (bitte mit eigenen Pfaden abgleichen):
fhem ALL=(ALL) NOPASSWD:/bin/systemctl

Für initd (bitte mit eigenen Pfaden abgleichen):
fhem ALL=(ALL) NOPASSWD:/usr/sbin/service
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Cobra am 23 November 2017, 16:36:17
Okay, und ich muss nicht das Verzeichnis sondern auf die Datei mit angeben?

Also:

pi ALL=(ALL) NOPASSWD:/etc/init.d/homebidge
pi ALL=(ALL) NOPASSWD:/etc/systemd/system/alexa.service
fhem ALL=(ALL) NOPASSWD:/etc/init.d/homebridge
fhem ALL=(ALL) NOPASSWD:/etc/systemd/system/alexa.service


Hat leider nicht geklappt. Oder wie finde ich genau raus welchen Pfad ich jetzt angeben muss? Sorry für die laienhafte Frage.

Oder liegt es daran dass auf dem Raspberry kein Nutzer fhem existiert?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 23 November 2017, 17:47:39
Zitat von: Cobra am 23 November 2017, 16:11:04
Hallo zusammen,

ich versuch mich auch gerade dran, scheitere aber irgendwie an den Rechten. Muss auch gestehen dass ich nicht der Linux-Profi bin.

Ich habe sowohl Homebridge als auch Alexa auf nem eigenen Raspberry laufen auf dem kein FHEM installiert ist.
Demnach dachte ich es reicht aus die Anleitung für den SSH Login mit dem Nutzer PI zu machen.

Nun kommt aber als Fehlermeldung immer

Permission denied please try again. Permission denied please try again. Permission denied (publickeypassword).

Hier mal das List von Alexa-Service:

Internals:
   CFGFN
   DEF        alexa pi@192.168.178.9
   NAME       Alexa_Service
   NOTIFYDEV  global
   NR         1046
   NTFY_ORDER 50-Alexa_Service
   SERVICENAME alexa
   STATE      error
   TYPE       serviced
   READINGS:
     2017-11-23 16:05:11   error           Permission denied please try again.  Permission denied please try again.  Permission denied (publickeypassword).
     2017-11-23 16:05:11   state           error
   helper:
Attributes:
   alias      Service alexa
   cmdIcon    restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY
   devStateIcon Initialized|status:light_question error|failed:light_exclamation running:audio_play:stop stopped:audio_stop:start stopping:audio_stop .*starting:audio_repeat
   genericDeviceType switch
   homebridgeMapping On=state,valueOff=/stopped|failed/,cmdOff=stop,cmdOn=start
StatusJammed=state,values=/error|failed/:JAMMED;/.*/:NOT_JAMMED
   icon       hue_room_garage
   room       Services
   serviceLogin pi@192.168.178.9
   webCmd     start:restart:stop:status


Hier die Statusmeldung vom Alexa-Service direkt auf dem PI:

pi@raspberrypiwz:~ $ sudo service alexa status
● alexa.service - Node.js Alexa Server
   Loaded: loaded (/etc/systemd/system/alexa.service; enabled)
   Active: active (running) since Thu 2017-11-23 16:01:55 CET; 5min ago
Main PID: 711 (alexa)
   CGroup: /system.slice/alexa.service
           └─711 alexa

Nov 23 16:02:02 raspberrypiwz alexa[711]: [11/23/2017, 4:02:02 PM] [FHEM] { ...,
Nov 23 16:02:02 raspberrypiwz alexa[711]: cmd: 'desired-temp',
Nov 23 16:02:02 raspberrypiwz alexa[711]: delay: true,
Nov 23 16:02:02 raspberrypiwz alexa[711]: minValue: 5,
Nov 23 16:02:02 raspberrypiwz alexa[711]: maxValue: 30,
Nov 23 16:02:02 raspberrypiwz alexa[711]: minStep: 0.5,
Nov 23 16:02:02 raspberrypiwz alexa[711]: device: 'WT.Schlafzimmer_Climate',
Nov 23 16:02:02 raspberrypiwz alexa[711]: informId: 'WT.Schlafzimmer_Climate...,
Nov 23 16:04:00 raspberrypiwz alexa[711]: 2017-11-23 16:04:00 caching: WT.Wo...7
Nov 23 16:04:01 raspberrypiwz alexa[711]: 2017-11-23 16:04:01 caching: WT.Sc...6
Hint: Some lines were ellipsized, use -l to show in full.


In /etc/sudoers (auf dem PI auf dem Alexa und Homebridge läuft) habe ich folgende Einträge gemacht:

fhem ALL=(ALL) NOPASSWD:/etc/init.d
pi ALL=(ALL) NOPASSWD:/etc/init.d
pi ALL=(ALL) NOPASSWD:/etc/systemd/system/
fhem ALL=(ALL) NOPASSWD:/etc/systemd/system/


Hab ich noch irgend etwas übersehen was gemacht werden muss?

Gruß Cobra

Der Benutzer, mit dem Du passwordless SSH eingerichtet hast, hat in seinem Homeverzeichnis einen Ordner .ssh. Also z.B. eingerichtet mit Benutzer pi Pfad /home/pi/.ssh.
Diese dort angelegten Daten braucht für die Benutzung mit FHEM nicht der Benutzer pi, sondern der Benutzer unter dem FHEM läuft (meist fhem).
Mit
sudo cp -R /home/pi/.ssh /opt/fhem
sudo chown -R fhem:dialout /opt/fhem/.ssh


Wird der Ordner .ssh in den Benutzerordner von FHEM kopiert und die Berechtigungen für den Benutzer fhem vergeben.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Cobra am 23 November 2017, 17:53:30
Super, danke für die Info.

Wollte gerade schreiben wie ich es lösen konnte.
Habe nämlich auch die letzte halbe Stunde versucht unter dem Nutzer fhem die Daten für den passwordless SSH zu generieren, dabei ist es dann letztendlich aber daran gescheitert dass ich sie mit der Anleitung die du verlinkt hast nicht auf den anderen Raspberry richtig kopieren konnte (Fehlende Verzeichnisse etc).

Mir hat dann folgende Seite geholfen:
http://www.linuxfun.de/homeautomation/fhem/ssh-befehle-auf-anderen-rechnern-mit-fhem-ausfuehren/ (http://www.linuxfun.de/homeautomation/fhem/ssh-befehle-auf-anderen-rechnern-mit-fhem-ausfuehren/)

Hab die Daten dann mit
ssh-copy-id -i /opt/fhem/.ssh/id_rsa.pub pi@IP-meines-Raspberrys
verschieben können.

Jetzt läuft es auch bei mir :-)

Danke
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 23 November 2017, 18:01:59
Zitat von: mahowi am 23 November 2017, 16:21:44
/etc/init.d und /etc/systemd/system/ sind Verzeichnisse.

Aus dem ersten Post:

Die Pfade ermitteln mit:
which systemctl
Oder (initd):
which service

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DS_Starter am 24 November 2017, 07:34:25
Morgen Dan,

vielen Dank für das Modul ..... feine Sache.  8)

Ich habe auch einen Einsatz dafür und ein paar Anmerkungen/Wünsche, bleibt ja nicht aus  ;)

* Attribute genericDeviceType, homebridgeMapping
  Die Attribute werden bei der Def gesetzt, aber es steht nicht in der commandref erläutert was die machen und wozu man sie braucht

* Reading "error"
  In dem Reading steht ja immer der letzte Fehler. Er bleibt aber auch stehen wenn der letzte Funktionsausfruf i.O. war und keinen Fehlerverursachte.
  Ich würde dafür plädieren, error tatsächlich nur mit dem Fehler zu füllen wenn es ihn auch gab und sonst error zu löschen oder mit "none" o.ä. zu   
  setzen.

Dann nich ein Wunsch.
Schön wäre m.M. nach Attribute z.B. "autoStart = 1....10", "autoStop=1....5".
Was sollen die bewirken ?  Der definierte Dienst würde beim Start von FHEM mit einer Verögerung von 1 ....10 Sekunden gestartet, bzw. beim "shutdown" automatisch gestoppt (der Stop von FHEM entsprechend mit einer Verzögerung von 1 ... 5 Sek. verzögert).

Ich habe z.B: einen Linux-Watchdog (NICHT fhem-watchdog) den ich auf diesem Weg nur laufen haben möchte wenn fhem regulär gestartet wird bzw. FHEM abstürzt. Wird FHEM regulär gestoppt, wird watchdog mit beendet. Dadurch wird die Überwachung mit beendet, sonst muss man ihn von Hand stoppen.

LG
Heiko
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: CoolTux am 24 November 2017, 07:54:19
Zitat von: DS_Starter am 24 November 2017, 07:34:25
* Reading "error"
  In dem Reading steht ja immer der letzte Fehler. Er bleibt aber auch stehen wenn der letzte Funktionsausfruf i.O. war und keinen Fehlerverursachte.
  Ich würde dafür plädieren, error tatsächlich nur mit dem Fehler zu füllen wenn es ihn auch gab und sonst error zu löschen oder mit "none" o.ä. zu   
  setzen.

Hallo Heiko,

Kurz meine persönliche Meinung dazu. Ich finde das das Reading genau so stehen bleiben sollte. So kann man sehen das es mal einen Fehler gab und selber einschätzen wie schwerwiegend das nun für einen selber ist. Ob der Fehler aktuell ist oder nicht kann man ja am Timestamp fest machen. Bei Deinem Vorschlag würden alte Fehler überschrieben werden.




Grüße
Leon
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: mahowi am 24 November 2017, 07:56:40
Zitat von: DS_Starter am 24 November 2017, 07:34:25
* Attribute genericDeviceType, homebridgeMapping
  Die Attribute werden bei der Def gesetzt, aber es steht nicht in der commandref erläütert was die machen und wozu sie man braucht

Die beiden Attribute kommen von Homebridge.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DS_Starter am 24 November 2017, 09:27:15
Morgen Leon und mahowi,

ich hatte mich davon leiten lassen dass im Logfile ohnehin vermerkt ist dass es einen Fehler gab.
Im Reading würde ich selbst nur aktuell gültige error-Einträge bevorzugen. Das wäre mir persönlich lieber  :D

@mahowi , ja ich wollte Dan nur darauf hinweisen was mir aus Sicht eines Anwenders auffällt. Ich nutze homebridge nicht und finde plötzlich Attribute gesetzt die nicht erläutert sind und mit denen ich als Anwender nichts anfangen kann. Im code habe ich ja gesehen dass er ein grep auf die globalen attr macht und abhängig davon im Device hinzufügt. Aber der normale Anwender wundert sich, liest in commandref nach und findet nichts.


LG
Heiko
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 24 November 2017, 14:31:22
Zitat von: DS_Starter am 24 November 2017, 07:34:25
* Attribute genericDeviceType, homebridgeMapping
  Die Attribute werden bei der Def gesetzt, aber es steht nicht in der commandref erläutert was die machen und wozu man sie braucht

Okay, hab's geändert. Die userattr werden nun überhaupt nicht mehr hinzugefügt. Es werden aber die Attribute homebridgeMapping und genericDeviceType gesetzt wenn das Attribut homebridgeMapping vorhanden ist. Ich gehe einfach mal davon aus dass diese auch benutzt werden könnten sofern diese vorhanden sind. Falls doch nicht benötigt, können die beiden Attribute einfach gelöscht werden, sie werden nicht wieder automatisch neu hinzugefügt.
commandref ist auch entsprechend ergänzt.

Zitat von: DS_Starter am 24 November 2017, 07:34:25
* Reading "error"
  In dem Reading steht ja immer der letzte Fehler. Er bleibt aber auch stehen wenn der letzte Funktionsausfruf i.O. war und keinen Fehlerverursachte.
  Ich würde dafür plädieren, error tatsächlich nur mit dem Fehler zu füllen wenn es ihn auch gab und sonst error zu löschen oder mit "none" o.ä. zu   
  setzen.

Obwohl ich eigentlich eher zu CoolTux' Meinung stehe, ärgere ich mich gerade bei der Entwicklung auch immer darüber dass die teilweise riesenlange Fehlermeldung stehen bleibt, obwohl längst alles richtig läuft.
Hab's jetzt mal angepasst und feuere ein "none" raus wenn alles okay ist. ;)

Zitat von: DS_Starter am 24 November 2017, 07:34:25
Dann nich ein Wunsch.
Schön wäre m.M. nach Attribute z.B. "autoStart = 1....10", "autoStop=1....5".
Was sollen die bewirken ?  Der definierte Dienst würde beim Start von FHEM mit einer Verögerung von 1 ....10 Sekunden gestartet, bzw. beim "shutdown" automatisch gestoppt (der Stop von FHEM entsprechend mit einer Verzögerung von 1 ... 5 Sek. verzögert).

Da stoße ich leider momentan an meine Grenzen! :o
Es werden bei shutdown/undef alle BlockingCalls gekillt, somit bliebe nur übrig das blockierend zu machen und das wäre unschön.
Autostart wäre machbar, macht aber m.E. wenig Sinn ohne Autostop.
Hast Du evtl. eine Idee Heiko?

Ich habe das Modul im ersten Beitrag mit den o.g. Änderungen aktualisiert.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DS_Starter am 24 November 2017, 15:14:55
Danke Dan  :D

wegen dem autoStop muss ich mal schauen wie ich das im DbLog gelöst habe.
Dort wird beim Shutdown auch im asynchronen Mode der cachewrite in die DB aufgerufen damit der Cache beim Shutdown weggeschrieben wird. Das passiert auch mit BlockingCall.

Werde mal heute Abend oder am WE ein bisschen basteln und melde mich wieder ob ich was erreicht habe.

Grüße,
Heiko
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 24 November 2017, 16:37:08
Hi Dan,

vielen Dank für das tolle Modul!!

Macht den Start u.a. von alexa-fhem deutlich charmanter! :)

EDIT: allerdings stimmt wohl etwas mit dem Status nicht so richtig... Ich nutze für alexa-fhem (noch) initd, also das Script unter /etc/init.d/     Bin dabei auf mein neues Testsystem umzusteigen und dabei hatte ich einen "Fehler" im Script (anlegen des Log: Pfad fehlt). Daher wurde mittels Start durch das Modul zwar gestartet und danach running angezeigt (auch nach Abfrage durch INFO) aber tatsächlich lief alexa-fhem nicht. Fehler im Startscript korrigiert und nun geht es und der Status stimmt auch...

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 24 November 2017, 16:55:17
Zitat von: MadMax-FHEM am 24 November 2017, 16:37:08
Hi Dan,

vielen Dank für das tolle Modul!!

Macht den Start u.a. von alexa-fhem deutlich charmanter! :)

EDIT: allerdings stimmt wohl etwas mit dem Status nicht so richtig... Ich nutze für alexa-fhem (noch) initd, also das Script unter /etc/init.d/     Bin dabei auf mein neues Testsystem umzusteigen und dabei hatte ich einen "Fehler" im Script (anlegen des Log: Pfad fehlt). Daher wurde mittels Start durch das Modul zwar gestartet und danach running angezeigt (auch nach Abfrage durch INFO) aber tatsächlich lief alexa-fhem nicht. Fehler im Startscript korrigiert und nun geht es und der Status stimmt auch...

Gruß, Joachim

Was hat denn in diesem Fehlerfall die Status Ausgabe aus der Konsole gezeigt?
sudo service alexa status
War darin zu sehen dass der Dienst nicht läuft?
Manchmal läuft ein Dienst zwar, schreibt dann aber in sein Logfile den eigentlichen Fehler und sieht für das System trotzdem so aus als wenn er läuft.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 24 November 2017, 16:57:35
Zitat von: DeeSPe am 24 November 2017, 16:55:17
Was hat denn in diesem Fehlerfall die Status Ausgabe aus der Konsole gezeigt?
sudo service alexa status
War darin zu sehen dass der Dienst nicht läuft?
Manchmal läuft ein Dienst zwar, schreibt dann aber in sein Logfile den eigentlichen Fehler und sieht für das System trotzdem so aus als wenn er läuft.

Gruß
Dan

Hi Dan,

leider nein, also lief tatsächlich nicht:


sudo /etc/init.d/alexa status
Alexa is not running
script done


bzw. so wie du es sehen wolltest:


sudo service alexa status
● alexa.service - LSB: Start daemon at boot time for alexa
   Loaded: loaded (/etc/init.d/alexa; generated; vendor preset: enabled)
   Active: active (exited) since Fri 2017-11-24 16:58:34 CET; 7s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1181 ExecStop=/etc/init.d/alexa stop (code=exited, status=0/SUCCESS)
  Process: 1239 ExecStart=/etc/init.d/alexa start (code=exited, status=0/SUCCESS)

Nov 24 16:58:31 MadMax-PI-FHEM-Test2 systemd[1]: Starting LSB: Start daemon at boot time for alexa...
Nov 24 16:58:31 MadMax-PI-FHEM-Test2 su[1243]: Successful su for pi by root
Nov 24 16:58:31 MadMax-PI-FHEM-Test2 su[1243]: + ??? root:pi
Nov 24 16:58:31 MadMax-PI-FHEM-Test2 su[1243]: pam_unix(su:session): session opened for user pi by (uid=0)
Nov 24 16:58:32 MadMax-PI-FHEM-Test2 alexa[1239]: -su: /home/pi/alexa-fhem/log/alexa-2017-11.log: No such file or directory
Nov 24 16:58:32 MadMax-PI-FHEM-Test2 alexa[1239]: Alexa starting
Nov 24 16:58:34 MadMax-PI-FHEM-Test2 alexa[1239]: Alexa is not running
Nov 24 16:58:34 MadMax-PI-FHEM-Test2 alexa[1239]: script done
Nov 24 16:58:34 MadMax-PI-FHEM-Test2 alexa[1239]: script done
Nov 24 16:58:34 MadMax-PI-FHEM-Test2 systemd[1]: Started LSB: Start daemon at boot time for alexa.


Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 24 November 2017, 17:11:56
Zitat von: MadMax-FHEM am 24 November 2017, 16:57:35
Hi Dan,

leider nein, also lief tatsächlich nicht:


sudo /etc/init.d/alexa status
Alexa is not running
script done


bzw. so wie du es sehen wolltest:


sudo service alexa status
● alexa.service - LSB: Start daemon at boot time for alexa
   Loaded: loaded (/etc/init.d/alexa; generated; vendor preset: enabled)
   Active: active (exited) since Fri 2017-11-24 16:58:34 CET; 7s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1181 ExecStop=/etc/init.d/alexa stop (code=exited, status=0/SUCCESS)
  Process: 1239 ExecStart=/etc/init.d/alexa start (code=exited, status=0/SUCCESS)

Nov 24 16:58:31 MadMax-PI-FHEM-Test2 systemd[1]: Starting LSB: Start daemon at boot time for alexa...
Nov 24 16:58:31 MadMax-PI-FHEM-Test2 su[1243]: Successful su for pi by root
Nov 24 16:58:31 MadMax-PI-FHEM-Test2 su[1243]: + ??? root:pi
Nov 24 16:58:31 MadMax-PI-FHEM-Test2 su[1243]: pam_unix(su:session): session opened for user pi by (uid=0)
Nov 24 16:58:32 MadMax-PI-FHEM-Test2 alexa[1239]: -su: /home/pi/alexa-fhem/log/alexa-2017-11.log: No such file or directory
Nov 24 16:58:32 MadMax-PI-FHEM-Test2 alexa[1239]: Alexa starting
Nov 24 16:58:34 MadMax-PI-FHEM-Test2 alexa[1239]: Alexa is not running
Nov 24 16:58:34 MadMax-PI-FHEM-Test2 alexa[1239]: script done
Nov 24 16:58:34 MadMax-PI-FHEM-Test2 alexa[1239]: script done
Nov 24 16:58:34 MadMax-PI-FHEM-Test2 systemd[1]: Started LSB: Start daemon at boot time for alexa.


Gruß, Joachim

Setz mal am serviced Gerät:
attr <name> serviceRegexFailed dead|failed|exited

Bin unsicher ob ich das als Default übernehmen sollte. ???

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 24 November 2017, 17:22:07
Hi Dan,

geht leider nicht:

dead|failed|exited not valid for serviceRegexFailed, must be a regex like 'dead|failed'!

Hab ein wenig rumprobiert aber irgendwie mag das Modul meine Eingaben nicht...

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 24 November 2017, 17:24:28
Zitat von: DeeSPe am 24 November 2017, 17:11:56
Setz mal am serviced Gerät:
attr <name> serviceRegexFailed dead|failed|exited

Bin unsicher ob ich das als Default übernehmen sollte. ???

Gruß
Dan

Zitat von: MadMax-FHEM am 24 November 2017, 17:22:07
Hi Dan,

geht leider nicht:

dead|failed|exited not valid for serviceRegexFailed, must be a regex like 'dead|failed'!

Hab ein wenig rumprobiert aber irgendwie mag das Modul meine Eingaben nicht...

Gruß, Joachim

Hab gerade gemerkt dass die Prüfung beim Setzen dieser Attribute nicht funktioniert.
Die Version im ersten Beitrag ist um den Fehler bereinigt und wie o.g. als Default übernommen.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 24 November 2017, 17:37:41
Hi Dan,

unverändert, also Anzeige "running" (auch nach INFO) obwohl der Dienst nicht läuft.

Bekomme folgendes im Log:

PERL WARNING: Use of uninitialized value $re in concatenation (.) or string at ./FHEM/98_serviced.pm line 241.

Sicherheitshalber habe ich das Attribut gesetzt wie genannt (klappt jetzt) aber genauso...

Sorry, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 24 November 2017, 18:03:35
Zitat von: MadMax-FHEM am 24 November 2017, 17:37:41
Hi Dan,

unverändert, also Anzeige "running" (auch nach INFO) obwohl der Dienst nicht läuft.

Bekomme folgendes im Log:

PERL WARNING: Use of uninitialized value $re in concatenation (.) or string at ./FHEM/98_serviced.pm line 241.

Sicherheitshalber habe ich das Attribut gesetzt wie genannt (klappt jetzt) aber genauso...

Sorry, Joachim

Alles gut, bin ja froh wenn jemand Schwachstellen aufdeckt.
Hab jetzt mal die Reihenfolge etwas für mich sinnvoller verändert, nun sollte es klappen.
Das Modul im ersten Beitrag ist aktualisiert.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 24 November 2017, 18:12:42
JUHUUU!

Also es wird failed angezeigt! :)

Vielen Dank!!

EDIT: bissi zu früh gejubelt... Jetzt steht auch beim Starten wo es gut geht "failed"... ;)

Gruß, Joachim

P.S.: bitte gerne für die "Unterstützung" (Schwachstellen aufdecken) ;)
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 24 November 2017, 18:31:14
Zitat von: MadMax-FHEM am 24 November 2017, 18:12:42
Also es wird failed angezeigt! :)

Was steht im Reading status?
Auf dieses werden die RegEx angewendet.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 24 November 2017, 18:34:49
Hier ein list nach Ausführen wo der Dienst läuft (also laut Status auf der Console):

Internals:
   CFGFN
   DEF        alexa
   NAME       alexa_fhem
   NR         64
   SERVICENAME alexa
   STATE      failed
   TYPE       serviced
   READINGS:
     2017-11-24 18:33:16   error           none
     2017-11-24 18:33:16   state           failed
     2017-11-24 18:33:16   status          Active: active (exited) since Fri 2017-11-24 18:33:16 CET; 134ms ago
   helper:
Attributes:
   alias      Service alexa
   cmdIcon    restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY
   devStateIcon Initialized|status:light_question error|failed:light_exclamation running:audio_play:stop stopped:audio_stop:start stopping:audio_stop .*starting:audio_repeat
   icon       hue_room_garage
   room       Services
   serviceInitd 1
   webCmd     start:restart:stop:status


EDIT: muss jetzt allerdings leider weg... Kann erst später wieder testen, SORRY!!!

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 24 November 2017, 18:38:17
Zitat von: MadMax-FHEM am 24 November 2017, 18:34:49

   READINGS:
     2017-11-24 18:33:16   status          Active: active (exited) since Fri 2017-11-24 18:33:16 CET; 134ms ago


Da steht doch auch wieder "exited"!
Vorhin stand genau das Gleiche da und der Dienst lief nicht?
Das ist aber merkwürdig. ???

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 24 November 2017, 23:43:59
Hallo Dan,

so, bin wieder zurück...

Ich poste mal ein paar Ausgaben von 'sudo service alexa status':

Start klappt und Service läuft:


pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa start
pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa status
● alexa.service - LSB: Start daemon at boot time for alexa
   Loaded: loaded (/etc/init.d/alexa; generated; vendor preset: enabled)
   Active: active (exited) since Fri 2017-11-24 23:37:54 CET; 4s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2986 ExecStop=/etc/init.d/alexa stop (code=exited, status=0/SUCCESS)
  Process: 3023 ExecStart=/etc/init.d/alexa start (code=exited, status=0/SUCCESS)

Nov 24 23:37:52 MadMax-PI-FHEM-Test2 systemd[1]: Starting LSB: Start daemon at boot time for alexa...
Nov 24 23:37:52 MadMax-PI-FHEM-Test2 su[3027]: Successful su for pi by root
Nov 24 23:37:52 MadMax-PI-FHEM-Test2 su[3027]: + ??? root:pi
Nov 24 23:37:52 MadMax-PI-FHEM-Test2 su[3027]: pam_unix(su:session): session opened for user pi by (uid=0)
Nov 24 23:37:52 MadMax-PI-FHEM-Test2 alexa[3023]: Alexa starting
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: Alexa is running PID 3037
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: script done
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: script done
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 systemd[1]: Started LSB: Start daemon at boot time for alexa.



Service gestoppt und läuft nicht:


pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa stop
pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa status
● alexa.service - LSB: Start daemon at boot time for alexa
   Loaded: loaded (/etc/init.d/alexa; generated; vendor preset: enabled)
   Active: inactive (dead) since Fri 2017-11-24 23:38:36 CET; 2s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 3098 ExecStop=/etc/init.d/alexa stop (code=exited, status=0/SUCCESS)
  Process: 3023 ExecStart=/etc/init.d/alexa start (code=exited, status=0/SUCCESS)

Nov 24 23:37:52 MadMax-PI-FHEM-Test2 su[3027]: pam_unix(su:session): session opened for user pi by (uid=0)
Nov 24 23:37:52 MadMax-PI-FHEM-Test2 alexa[3023]: Alexa starting
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: Alexa is running PID 3037
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: script done
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: script done
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 systemd[1]: Started LSB: Start daemon at boot time for alexa.
Nov 24 23:38:36 MadMax-PI-FHEM-Test2 systemd[1]: Stopping LSB: Start daemon at boot time for alexa...
Nov 24 23:38:36 MadMax-PI-FHEM-Test2 alexa[3098]: Alexa closed
Nov 24 23:38:36 MadMax-PI-FHEM-Test2 alexa[3098]: script done
Nov 24 23:38:36 MadMax-PI-FHEM-Test2 systemd[1]: Stopped LSB: Start daemon at boot time for alexa.



Und dann einmal, wenn der Service beim Start einen Fehler hat, also bei "Statusabfrage" dann nicht läuft:


pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa start
pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa status
● alexa.service - LSB: Start daemon at boot time for alexa
   Loaded: loaded (/etc/init.d/alexa; generated; vendor preset: enabled)
   Active: active (exited) since Fri 2017-11-24 23:41:26 CET; 5s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 3098 ExecStop=/etc/init.d/alexa stop (code=exited, status=0/SUCCESS)
  Process: 3167 ExecStart=/etc/init.d/alexa start (code=exited, status=0/SUCCESS)

Nov 24 23:41:24 MadMax-PI-FHEM-Test2 systemd[1]: Starting LSB: Start daemon at boot time for alexa...
Nov 24 23:41:24 MadMax-PI-FHEM-Test2 su[3171]: Successful su for pi by root
Nov 24 23:41:24 MadMax-PI-FHEM-Test2 su[3171]: + ??? root:pi
Nov 24 23:41:24 MadMax-PI-FHEM-Test2 su[3171]: pam_unix(su:session): session opened for user pi by (uid=0)
Nov 24 23:41:24 MadMax-PI-FHEM-Test2 alexa[3167]: -su: /home/pi/alexa-fhem/log/alexa-2017-11.log: No such file or directory
Nov 24 23:41:24 MadMax-PI-FHEM-Test2 alexa[3167]: Alexa starting
Nov 24 23:41:26 MadMax-PI-FHEM-Test2 alexa[3167]: Alexa is not running
Nov 24 23:41:26 MadMax-PI-FHEM-Test2 alexa[3167]: script done
Nov 24 23:41:26 MadMax-PI-FHEM-Test2 alexa[3167]: script done
Nov 24 23:41:26 MadMax-PI-FHEM-Test2 systemd[1]: Started LSB: Start daemon at boot time for alexa.


Ich hoffe das hilft (ein wenig)...

EDIT: jetzt bin ich selbst verwirrt... Ich dachte schon ich hätte einen copy/paste-Fehler aber es ist tatsächlich so, dass nach einem Stop die quasi fast identische Ausgabe zu nach einem Start kommt... Wohin gegen folgende Abfrage die richtige "Antwort" gibt:


pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo /etc/init.d/alexa status
Alexa is not running
script done


EDIT2: Hier noch ein paar Infos zum System: PI3 Raspbian Stretch lite (jaja, ich weiß: eigentlich systemd aber ich ziehe grad um von Wheezy), fhem (fast / denke knapp 2 Wochen letzter Update) aktuell (eben ein Update gemacht)...

Danke, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DS_Starter am 25 November 2017, 11:05:29
Hallo Dan,

anghängt habe ich dir die V1.0.0.

Autostart und Autostop läuft bei mir einwandfrei.
Autostart kann mit einer Verzögerung von 1...10 Sekunden den Service starten.
Eine Versionierung habe ich mit eingebaut und NOTIFYDEV auf global gesetzt wegen der INITIALIZED-Verarbeitung beim Start.

Meine Ergänzungen habe ich mit "DS_Starter" kenntlich gemacht. Wenn du danach suchst findest du alle Changes.

Probiers mal aus und wenn es dir gefällt ergänze ich auch noch die Commandref  ;)

EDIT: beim start von fhem wird der service-status jetzt automatisch ermittelt wenn kein autostart gesetzt ist, mit autostart geschieht das ja implizit.

bis später ...

LG,
Heiko
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DS_Starter am 25 November 2017, 18:12:03
Hi Dan,

habe in der angehängten V1.1.0 noch eine kleine Verbesserung eingebaut.

Das Attr autoStop hat jetzt einen größeren Wertevorrat und beschreibt die maximale Zeit die nach dem shutdown-Kommando auf die erfolgreiche Abarbeitung des BlockingCall gewartet wird. Stirbt der BlockingCall oder hängt weil der zu stoppende Dienst nicht reagiert o.ä. würde FHEM sonst eventuell nicht stoppen und ewig in der Schleife hängen.
Mit dieser Version kann das nicht passieren und der shutdown wird nach Ablauf der Zeit forciert, unabhängig vom Erfolg des BlockingCall.
Ist bei mir noch nicht passiert ...  reine Vorsichtsmaßnahme.

LG,
Heiko
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 25 November 2017, 18:36:10
Danke für Deine Zuarbeit Heiko, das schätze ich sehr.
Ich hab Deine V1.0.0 Änderungen "in meinem Stil" bei mir soweit übernommen.
Musste erst mal verstehen was da passiert und einige Dinge fand ich für mein Code-Verständnis umständlich, z.B. der zusätzliche Prototype in SetFn.
Das ist wohl aber meine persönliche Macke... :o

Werde Deine Änderungen von V1.1.0 auch noch versuchen zu übernehmen und dann aktualisiere ich das Modul im ersten Beitrag.

Zitat von: MadMax-FHEM am 24 November 2017, 23:43:59
Hallo Dan,

so, bin wieder zurück...

Ich poste mal ein paar Ausgaben von 'sudo service alexa status':

Start klappt und Service läuft:


pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa start
pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa status
● alexa.service - LSB: Start daemon at boot time for alexa
   Loaded: loaded (/etc/init.d/alexa; generated; vendor preset: enabled)
   Active: active (exited) since Fri 2017-11-24 23:37:54 CET; 4s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2986 ExecStop=/etc/init.d/alexa stop (code=exited, status=0/SUCCESS)
  Process: 3023 ExecStart=/etc/init.d/alexa start (code=exited, status=0/SUCCESS)

Nov 24 23:37:52 MadMax-PI-FHEM-Test2 systemd[1]: Starting LSB: Start daemon at boot time for alexa...
Nov 24 23:37:52 MadMax-PI-FHEM-Test2 su[3027]: Successful su for pi by root
Nov 24 23:37:52 MadMax-PI-FHEM-Test2 su[3027]: + ??? root:pi
Nov 24 23:37:52 MadMax-PI-FHEM-Test2 su[3027]: pam_unix(su:session): session opened for user pi by (uid=0)
Nov 24 23:37:52 MadMax-PI-FHEM-Test2 alexa[3023]: Alexa starting
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: Alexa is running PID 3037
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: script done
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: script done
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 systemd[1]: Started LSB: Start daemon at boot time for alexa.



Service gestoppt und läuft nicht:


pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa stop
pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa status
● alexa.service - LSB: Start daemon at boot time for alexa
   Loaded: loaded (/etc/init.d/alexa; generated; vendor preset: enabled)
   Active: inactive (dead) since Fri 2017-11-24 23:38:36 CET; 2s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 3098 ExecStop=/etc/init.d/alexa stop (code=exited, status=0/SUCCESS)
  Process: 3023 ExecStart=/etc/init.d/alexa start (code=exited, status=0/SUCCESS)

Nov 24 23:37:52 MadMax-PI-FHEM-Test2 su[3027]: pam_unix(su:session): session opened for user pi by (uid=0)
Nov 24 23:37:52 MadMax-PI-FHEM-Test2 alexa[3023]: Alexa starting
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: Alexa is running PID 3037
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: script done
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 alexa[3023]: script done
Nov 24 23:37:54 MadMax-PI-FHEM-Test2 systemd[1]: Started LSB: Start daemon at boot time for alexa.
Nov 24 23:38:36 MadMax-PI-FHEM-Test2 systemd[1]: Stopping LSB: Start daemon at boot time for alexa...
Nov 24 23:38:36 MadMax-PI-FHEM-Test2 alexa[3098]: Alexa closed
Nov 24 23:38:36 MadMax-PI-FHEM-Test2 alexa[3098]: script done
Nov 24 23:38:36 MadMax-PI-FHEM-Test2 systemd[1]: Stopped LSB: Start daemon at boot time for alexa.



Und dann einmal, wenn der Service beim Start einen Fehler hat, also bei "Statusabfrage" dann nicht läuft:


pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa start
pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo service alexa status
● alexa.service - LSB: Start daemon at boot time for alexa
   Loaded: loaded (/etc/init.d/alexa; generated; vendor preset: enabled)
   Active: active (exited) since Fri 2017-11-24 23:41:26 CET; 5s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 3098 ExecStop=/etc/init.d/alexa stop (code=exited, status=0/SUCCESS)
  Process: 3167 ExecStart=/etc/init.d/alexa start (code=exited, status=0/SUCCESS)

Nov 24 23:41:24 MadMax-PI-FHEM-Test2 systemd[1]: Starting LSB: Start daemon at boot time for alexa...
Nov 24 23:41:24 MadMax-PI-FHEM-Test2 su[3171]: Successful su for pi by root
Nov 24 23:41:24 MadMax-PI-FHEM-Test2 su[3171]: + ??? root:pi
Nov 24 23:41:24 MadMax-PI-FHEM-Test2 su[3171]: pam_unix(su:session): session opened for user pi by (uid=0)
Nov 24 23:41:24 MadMax-PI-FHEM-Test2 alexa[3167]: -su: /home/pi/alexa-fhem/log/alexa-2017-11.log: No such file or directory
Nov 24 23:41:24 MadMax-PI-FHEM-Test2 alexa[3167]: Alexa starting
Nov 24 23:41:26 MadMax-PI-FHEM-Test2 alexa[3167]: Alexa is not running
Nov 24 23:41:26 MadMax-PI-FHEM-Test2 alexa[3167]: script done
Nov 24 23:41:26 MadMax-PI-FHEM-Test2 alexa[3167]: script done
Nov 24 23:41:26 MadMax-PI-FHEM-Test2 systemd[1]: Started LSB: Start daemon at boot time for alexa.


Ich hoffe das hilft (ein wenig)...

EDIT: jetzt bin ich selbst verwirrt... Ich dachte schon ich hätte einen copy/paste-Fehler aber es ist tatsächlich so, dass nach einem Stop die quasi fast identische Ausgabe zu nach einem Start kommt... Wohin gegen folgende Abfrage die richtige "Antwort" gibt:


pi@MadMax-PI-FHEM-Test2:/opt/fhem/FHEM $ sudo /etc/init.d/alexa status
Alexa is not running
script done


EDIT2: Hier noch ein paar Infos zum System: PI3 Raspbian Stretch lite (jaja, ich weiß: eigentlich systemd aber ich ziehe grad um von Wheezy), fhem (fast / denke knapp 2 Wochen letzter Update) aktuell (eben ein Update gemacht)...

Danke, Joachim

Das ist mir irgendwie noch rätselhaft, könnte da was mit dem init Skript nicht hinhauen?

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 25 November 2017, 19:00:26
Zitat von: DeeSPe am 25 November 2017, 18:36:10
Das ist mir irgendwie noch rätselhaft, könnte da was mit dem init Skript nicht hinhauen?

Gruß
Dan

Hallo Dan,

die Idee ist mir auch schon gekommen...

Frägt sich nur: was...

Ich habe es aus dem alexa-fhem Wiki bzw. aus der Weiterverlinkung zu homebridge...

Aber ich werde es mal mit anderen Scripten in init.d vergleichen...

Ich werde das Modul von dir auch mal auf meinem Testsystem mit Wheezy ausprobieren (solange ich das noch habe)...
...und evtl. noch Jessie.

Nur um auszuschließen, dass es damit zu tun hat.

Auf lange Sicht werde ich aber eh auf systemd umstellen aber solange es dir hilft werde ich noch etwas testen (bzw. brauche ich auch erst mal Zeit umzustellen / ziehe ja gerade mein gesamtes Testsystem von Wheezy um auf Stretch aber halt nicht komplett [war/ist ganz schön "zugemüllt"] sondern nur die Dinge die ich zum Testen brauche bzw. noch in Erprobung sind bevor es dann auf's Hauptsystem [oder in die Tonne] geht)...

Komme aber wohl erst morgen wieder dazu... :-|

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: synaps-o-dan am 25 November 2017, 19:06:22
Coole Idee, werde ich ausprobieren. Eine Frage vorab: aktuell ist bei mir der user fhem kein sudoer, sondern hat nur relativ eingeschränkt Rechte. Spricht aus Sicherheitsgründen irgendetwas dagegen, dem user fhem Zugriff auf systemd zu erlauben? Wenn fhem von außen (trotz bestmöglicher Absicherung) gekapert wird?
Liebe Grüße,
Daniel
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DS_Starter am 25 November 2017, 19:10:30
Hi Dan,

ja, jeder hat so seinen Sti. Ich bin schon älter und brauche vor Allem Übersichtlichkeit, sonst sehe ich den Wald vor lauter Bäumen nicht und die Augen schmerzen beim Lesen von Code ohne Zwischenräumen.  :)

Helfe dir gerne wenn ich kann und teste/verbessere mit.
Finde es ein sehr hilfreiches Modul ! und einen Einsatz habe ich bereits ... da kommt sicherlich noch etwas dazu.

LG,
Heiko
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DS_Starter am 26 November 2017, 08:45:58
Hallo Dan,

nochmal eine kleine Änderung. Es hat sich als hilfreich erwiesen den Wertevorrat für das attr autoStart bis in den Minutenbereich hinein zu erweitern.
Das macht sich beim watchdog gut, da erst die heartbeat-Datei geschrieben sein muß bevor der Dienst gestart wird.

Demzufolge habe ich serviced_Notify so abgeändert dass in jedem Fall beim fhem Start der aktuelle Status ermittelt wird und nicht nur wenn autoStart != 0.
Version 1.2.0 ist anbei.

LG,
Heiko
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 26 November 2017, 23:10:05
Hallo Dan,

also irgendwie ist das mit initd wohl nicht so einfach...

Ich habe mal mit der vorletzten Version (die vor Erweiterung um Heikos Code, also die selbe die ich zuvor auf dem Stretch System getestet hatte) auf einem wheezy System installiert und auch mal ein anderes Startscript (ha-bridge) genutzt.

Beim Start dann folgendes:


error Starting habridge 2017-11-26 23:00:52
state error 2017-11-26 23:00:52


Obwohl ha-bridge startet und läuft...

Eine Abfrage von "Info" durch das Modul führt dazu, dass der ReadingsTimestamp des Readings state laufend hoch gezählt wird.
Eine erneute Abfrage durch "Info" wird wie folgt "quittiert":

Work already/still in progress... Please wait for the current process to finish.

Wie lange das so geht weiß ich nicht...
...weil ich dann den Service wieder "deinstalliert" habe, dann ist auf jeden Fall "Ruhe"...

Dort (Wheezy mit dem ha-bridge Service)  sind die Ausgaben von "sudo service ha-bridge status" ganz anders.
Nur "Stopped" oder "Running"...


Nur als kurze Zwischen-Info.


Nächste Schritte (außer du sagst das ist Quatsch/uninteressant oder teste lieber das oder so):

- alexa Startscript auf das Wheezy System bringen.
- neueste Version des Moduls auf Wheezy und Stretch testen.
- verschiedene Startscripte vergleichen bzw. herausfinden wie denn ein "richtiges" Startscript aussehen muss.
(- umstellen auf systemd / aber dann natürlich kein Test mehr bzgl. initd)

Gruß, Joachim

P.S.: sorry für all die komischen Probleme...
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 27 November 2017, 00:28:31
Ich habe v.1.2.1 im ersten Beitrag hochgeladen.

Heikos Codespenden habe ich in meinem Stil eingepflegt.
Da alle Attribute bei mir modulspezifisch geprefixt sind heißen sie nun serviceAutostart und serviceAutostop. Werte lassen sich von 1-99 frei setzen.

@Heiko:
Ich habe zum BlockingCall noch eine AbortFn mit 10sec Timeout hinzugefügt, nur um ganz sicher zu gehen. ;)
Deine Codeerweiterung aus v1.2.0 hatte ich schon beim Einpflegen des v1.1.0 Codes mit hinzugefügt.
Bitte schaue mal nach ob noch alles, trotz verändertem Code, funktioniert wie es soll.
Und natürlich nochmal extra Dank an Dich.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 27 November 2017, 00:34:11
Zitat von: MadMax-FHEM am 26 November 2017, 23:10:05
Hallo Dan,

also irgendwie ist das mit initd wohl nicht so einfach...

Ich habe mal mit der vorletzten Version (die vor Erweiterung um Heikos Code, also die selbe die ich zuvor auf dem Stretch System getestet hatte) auf einem wheezy System installiert und auch mal ein anderes Startscript (ha-bridge) genutzt.

Beim Start dann folgendes:


error Starting habridge 2017-11-26 23:00:52
state error 2017-11-26 23:00:52


Obwohl ha-bridge startet und läuft...

Eine Abfrage von "Info" durch das Modul führt dazu, dass der ReadingsTimestamp des Readings state laufend hoch gezählt wird.
Eine erneute Abfrage durch "Info" wird wie folgt "quittiert":

Work already/still in progress... Please wait for the current process to finish.

Wie lange das so geht weiß ich nicht...
...weil ich dann den Service wieder "deinstalliert" habe, dann ist auf jeden Fall "Ruhe"...

Dort (Wheezy mit dem ha-bridge Service)  sind die Ausgaben von "sudo service ha-bridge status" ganz anders.
Nur "Stopped" oder "Running"...


Nur als kurze Zwischen-Info.


Nächste Schritte (außer du sagst das ist Quatsch/uninteressant oder teste lieber das oder so):

- alexa Startscript auf das Wheezy System bringen.
- neueste Version des Moduls auf Wheezy und Stretch testen.
- verschiedene Startscripte vergleichen bzw. herausfinden wie denn ein "richtiges" Startscript aussehen muss.
(- umstellen auf systemd / aber dann natürlich kein Test mehr bzgl. initd)

Gruß, Joachim

P.S.: sorry für all die komischen Probleme...

Ganz ehrlich, ich bin kein Experte für initd und/oder systemd.
Allerdings würde ich von allen Linux Diensten erwarten dass sie ihren Status "ehrlich" bekannt geben.
Soll bedeuten, wenn ein Dienst beim Start nicht richtig ausgeführt werden kann (warum auch immer), dann sollte das auch eindeutig im Status zu erkennen sein.
Evtl. liege ich aber auch falsch, wie gesagt bin da kein Experte, würde mich aber freuen wenn wir das aufklären könnten.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 27 November 2017, 00:40:51
Zitat von: synaps-o-dan am 25 November 2017, 19:06:22
Coole Idee, werde ich ausprobieren. Eine Frage vorab: aktuell ist bei mir der user fhem kein sudoer, sondern hat nur relativ eingeschränkt Rechte. Spricht aus Sicherheitsgründen irgendetwas dagegen, dem user fhem Zugriff auf systemd zu erlauben? Wenn fhem von außen (trotz bestmöglicher Absicherung) gekapert wird?
Liebe Grüße,
Daniel

Es ist natürlich immer eine Sicherheitsschwachstelle wenn der FHEM ausführende Benutzer weitreichende Rechte (sudo) hat.
FHEM bietet aber Möglichkeiten um in der aus dem Internet erreichbaren Instanz entsprechende Maßnahmen zu ergreifen dass diesbezüglich möglichst nichts passieren kann.
Sicherheit sollte immer Bedacht werden und jedem sollte bewußt sein dass man natürlich die Sicherheit schwächt wenn man sudo-Rechte erteilt.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DS_Starter am 27 November 2017, 08:36:01
Morgen Dan,

Version 1.2.1 läuft leider nicht mehr so reibungslos wie 1.2.0.
Habe kurz angetestet:

* Startverzögerung von 2 Minuten oder höher (10) geht nicht mehr -> 3 Stellen in autoStart zulassen
* beim Autostop wird das controlfile nicht mehr automatisch gelöscht dadurch immer force shutdown nach Ablauf Autostopzeit
   Log: 
  2017.11.27 07:53:48.936 3: watchdog: stopping service "watchdog" due to shutdown
  2017.11.27 07:54:10.592 3: watchdog: Maximum shutdown waittime of 20 seconds excceeded. Controlfile "./log/watchdog_shut.lock" deleted and 
  force sutdown.

* beim autostart wird komischerweise angenommen es handele sich um shutdown-Sequenz (habe eine
   Logausgabe eigebaut damit man das sieht)
  Log: 
  2017.11.27 07:54:15.214 3: watchdog: starting service "watchdog" with delay of 99 seconds
  2017.11.27 07:54:15.650 2: watchdog: Sghutseq: 1
  2017.11.27 07:54:15.653 2: watchdog: error while deleting controlfile "./log/watchdog_shut.lock": ./log/watchdog_shut.lock: Datei oder Verzeichnis 
  nicht gefunden

* beim fhem start wird, wenn autostart angegeben, der aktuelle Status des service nicht mehr automatisch ermittelt. Der Status des Service steht nach 
   Start auf "stopping" solange bis der service nach der verzögerung gestartet wird. "stopping" ist wahrscheinlich der letzte status beim stop von fhem
  (wenn autostop ein)

Erstmal die kurze Info. Muss jetzt los und schaue heute Abend genauer was da nicht stimmt. Wenn du Zeit hast kannst du ja schon mal schauen.

LG,
Heiko
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 27 November 2017, 13:13:52
Zitat von: DS_Starter am 27 November 2017, 08:36:01
* Startverzögerung von 2 Minuten oder höher (10) geht nicht mehr -> 3 Stellen in autoStart zulassen

Verstanden, ändere ich auf 3 Stellen, begrenze aber auf 300.

Zitat von: DS_Starter am 27 November 2017, 08:36:01
* beim Autostop wird das controlfile nicht mehr automatisch gelöscht dadurch immer force shutdown nach Ablauf Autostopzeit
   Log: 
  2017.11.27 07:53:48.936 3: watchdog: stopping service "watchdog" due to shutdown
  2017.11.27 07:54:10.592 3: watchdog: Maximum shutdown waittime of 20 seconds excceeded. Controlfile "./log/watchdog_shut.lock" deleted and 
  force sutdown.

Schaue ich mir an, lief aber gestern bei mir. ::)

Zitat von: DS_Starter am 27 November 2017, 08:36:01
* beim fhem start wird, wenn autostart angegeben, der aktuelle Status des service nicht mehr automatisch ermittelt. Der Status des Service steht nach 
   Start auf "stopping" solange bis der service nach der verzögerung gestartet wird. "stopping" ist wahrscheinlich der letzte status beim stop von fhem
  (wenn autostop ein)

Das ist von mir beabsichtigt.
Hintergrund dazu:
Die letzten Readings werden ja beim Start von FHEM automatisch wiederhergestellt, also z.B. genau der letzte Status vor dem Shutdown. Und so soll es ja auch sein. Wenn also serviceStatusInterval nicht gesetzt ist sehe ich damit keinen Grund den Status explizit neu abzurufen.
Bin allerdings noch nicht ganz glücklich damit.
Eigentlich müsste der abschließende BlockingCall, der den Service stoppt, noch sauber zurückkehren und das state Reading aktualisieren und wirklich auf "stopped" setzen. Durch BlockingKill in UndefFn wird das aber m.E. verhindert.
Weißt Du in welcher Reihenfolge UndefFn und ShutdownFn aufgerufen werden? Kann man evtl. BlockingKill in die ShutdownFn packen?
Mit dieser/Deiner Shutdown Logik bin ich noch nicht ganz "grün". :)

Ich probiere mal noch etwas, vielleicht klappt das ja...

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 28 November 2017, 00:17:05
Mit der netten Hilfe von Heiko konnten wir das Problem lösen.
serviceShutdown funktioniert nun wie erwartet.

Das Modul im ersten Beitrag ist auf Version v1.2.3 aktualisiert.
+ neues Attribut serviceGetStatusOnInit

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 28 November 2017, 00:31:58
Zitat von: synaps-o-dan am 25 November 2017, 19:06:22
Coole Idee, werde ich ausprobieren. Eine Frage vorab: aktuell ist bei mir der user fhem kein sudoer, sondern hat nur relativ eingeschränkt Rechte. Spricht aus Sicherheitsgründen irgendetwas dagegen, dem user fhem Zugriff auf systemd zu erlauben? Wenn fhem von außen (trotz bestmöglicher Absicherung) gekapert wird?
Liebe Grüße,
Daniel

Wenn Du bspw. unter systemd nur für einen bestimmten Dienst sudo Rechte erteilen willst, dann kann Du das z.B. so in der sudoers limitieren (hier im Beispiel mit Dienst homebridge):
fhem    ALL=(ALL) NOPASSWD:/bin/systemctl * homebridge

Weitere Dienst zum Erlauben kommagetrennt anhängen.

Es ist auch möglich nur die Status-Abfrage zu erlauben:
fhem    ALL=(ALL) NOPASSWD:/bin/systemctl status homebridge

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: raiderxxl am 01 Dezember 2017, 15:25:01
Hi,
Tolles Modul!
Habe gleich mal meine wichtigsten Dienste eingebunden(VMWARE/UbuntuServer):
Dienste lassen sich Starten,Stoppen und Restarten.... prima! Nur beim Status habe ich ein Prolem

fhem: state running           status Active: active (running) since Mo 2017-11-27 13:35:22 CET; 4 days ago
habridge: state running      status Active: active (running) since Fr 2017-12-01 15:01:24 CET; 41ms ago
homebridge: state failed      status Active: active (exited) since Fr 2017-12-01 15:08:04 CET; 1min 37s ago

homebridge läuft und Funktioniert... ich habe gelesen das das andere auch hatten, was kann ich tun damit das funktioniert?

Mein eingesetzte Version:
my $servicedVersion = "1.2.3";

Grüßle

Pascal

Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 01 Dezember 2017, 21:34:13
Zitat von: raiderxxl am 01 Dezember 2017, 15:25:01
homebridge: state failed      status Active: active (exited) since Fr 2017-12-01 15:08:04 CET; 1min 37s ago

homebridge läuft und Funktioniert... ich habe gelesen das das andere auch hatten, was kann ich tun damit das funktioniert?

Sicher dass homebridge richtig läuft?
Laut dem Status sieht das nicht so aus.

Alle RegEx können über die Attribute serviceRegex... selbst angepasst werden.
Die RegEx werden in folgender Reihenfolge abgearbeitet:
serviceRegexStarting
serviceRegexStopped
serviceRegexFailed
serviceRegexStarted

Sobald ein RegEx matcht wird dieser als state übernommen.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 18 Dezember 2017, 14:38:44
Zitat von: DeeSPe am 01 Dezember 2017, 21:34:13
Alle RegEx können über die Attribute serviceRegex... selbst angepasst werden.
Die RegEx werden in folgender Reihenfolge abgearbeitet:
serviceRegexStarting
serviceRegexStopped
serviceRegexFailed
serviceRegexStarted

Sobald ein RegEx matcht wird dieser als state übernommen.

Gruß
Dan

Hi Dan,

so nun hatte ich endlich wieder Zeit mich dem Thema zu widmen...

Und was soll ich sagen: es läuft! Vielen Dank noch mal für das Modul!

Das mit den RegEx war für mich sehr wichtig, habe sie bei systemd wie folgt gesetzt:


serviceRegexFailed failed
serviceRegexStarted active
serviceRegexStopped inactive|dead


Und dann musste ich einige Zeit in das Starten/Stoppen von Servies mit initd investieren.

Folgendes habe ich rausgefunden (zumindest bei mir so: PI3 Raspberry Stretch lite):

sobald das Startscript mal gut zurück gemeldet hat gibt die Abfrage:

sudo service alexa status

einfach
Active: active (exited) since Mon 2017-12-18 14:26:05 CET; 4s ago
aus.

Selbst wenn dann der Service/Prozess gar nicht mehr läuft und das Startscript das sehr wohl beim Aufruf "status" melden würde...
...daher sieht es für mich so aus, als ob der Service-Handler seine eigenen Status-Zustände hält und zwar die beim Start/Stop.

D.h. der Service bleibt solange "running" bis er per Kommando "service alexa stop" gestoppt wurde.
Alle anderen Möglichkeiten den Service zu stoppen (inkl. Absturz) interessieren nicht.

Hat lange gedauert das so rauszufinden...

Dann habe ich mir das alexa Startscript mal angesehen.
Dort wird gestartet und Fehler beim Start konnte ich so irgendwie (noch) nicht abfangen.
Daher wird dort immer einfach "ok" zurück gegeben...

In der "normalen" Nutzung per DOIF und Dummy aus fhem heraus ist das auch kein Problem.
Es wird 2 Sekunden gewartet und dann das Script noch mal mit "status" aufgerufen (macht das Script selbst).

Wenn dann irgendwas nicht stimmt, dann wird der Status des Dummy in fhem ja richtig gesetzt und man weiß Bescheid.
(Status wird vom Script per setreading bzw. set beim Dummy aktualisiert)

Allerdings bekommt der Service-Manager davon nichts mit (es wird ja beim Starten immer "ok" zurückgegeben).
Und da der nicht wirklich das Script mit "status" aufruft, um den Status abzufragen bleibt er halt bei "running"... :-|

Also habe ich das Script umgebaut und warte nun 5s und prüfe dann direkt nach dem Startvorgang, ob der Dienst auch tatsächlich läuft (also so wie das Script es bei "status" auch tun würde) und gebe das dann zurück.

So bekomme ich nun auch mit, wenn beim Starten (zumindest innerhalb der ersten 5s) was schief gelaufen ist.

Da das alexa Startscript und das homebridge Startscript ja irgendwie ähnlich sind, vielleicht hilft das auch dort...

Gruß, Joachim

EDIT:
Statusabfrage nach Stop liefert:
Active: inactive (dead) since Mon 2017-12-18 14:44:07 CET; 1s ago

und bei Fehler (festgestellt vom Scriot beim Start innerhalb der ersten 5s und exit code 7):
Active: failed (Result: exit-code) since Mon 2017-12-18 14:46:35 CET; 4s ago
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 18 Dezember 2017, 21:37:45
Hallo Joachim,

schön dass es nun bei Dir läuft und danke für die Rückmeldung.

Bei mir läuft homebridge als systemd und macht keinerlei Probleme mit diesem Modul.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: no_Legend am 16 Januar 2018, 19:32:57
Hi,
habe das Modul in Version 1.2.3 installiert.

Nun wollte ich mit Homebridge testen.
Start Script für Homebridge würde hier nach erstellt: https://github.com/nfarina/homebridge/wiki/Homebridge-autostart-at-boot-(init.d)-on-Ubuntu-(linux)
Auf der Konsole geht es ohne Problem.
In FHEM bekomme ich immer nur bei INFO also State "FAILED angezeigt.
Allerdings unter status:

Active: active (exited) since Di 2018-01-16 19:27:28 CET; 11s ago


Jemand ne Idee?

Gruß Robert
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 16 Januar 2018, 19:55:33
Zitat von: DeeSPe am 01 Dezember 2017, 21:34:13
Alle RegEx können über die Attribute serviceRegex... selbst angepasst werden.
Die RegEx werden in folgender Reihenfolge abgearbeitet:
serviceRegexStarting
serviceRegexStopped
serviceRegexFailed
serviceRegexStarted

Sobald ein RegEx matcht wird dieser als state übernommen.

Entweder selbst die RegEx(s) anpassen und/oder wenn Dein System systemd unterstützt entsprechend homebridge gleich als systemd (https://gist.github.com/johannrichard/0ad0de1feb6adb9eb61a) statt initd einrichten.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: no_Legend am 16 Januar 2018, 20:59:31
Zitat von: DeeSPe am 16 Januar 2018, 19:55:33
Entweder selbst die RegEx(s) anpassen und/oder wenn Dein System systemd unterstützt entsprechend homebridge gleich als systemd (https://gist.github.com/johannrichard/0ad0de1feb6adb9eb61a) statt initd einrichten.

Gruß
Dan

Danke Dan, hab ich gemacht.
Geht nun hatte noch ein problem mit dem Pfad zu Homebridge, hab ihn angepasst dann ging es.

Danke und Gruß Robert
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: no_Legend am 20 Januar 2018, 08:13:20
Läuft bei mir sehr Stabil.
Ist ein commit in das offiziell Repo geplant?

Gruß Robert
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 20 Januar 2018, 09:11:13
Zitat von: no_Legend am 20 Januar 2018, 08:13:20
Ist ein commit in das offiziell Repo geplant?

Ja, wird es geben.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: no_Legend am 20 Januar 2018, 09:17:23
Danke für deine schnelle Antwort.
Und danke für deine Arbeit

Gruß Robert
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RaspiLED am 20 Januar 2018, 10:39:46
*Bedankt*

Ich wollte nur mal schnell Danke sagen! Dein Modul ist super!
Hier mal als Idee für andere meine use cases:
- HomeBridge und FHEM neustarten  (stop gemappt auf restart) um Homekit Room neu in HomeBridge einzulesen
- VPNC über HomeBridge starten und somit von außen jederzeit eine Verbindung von Innen aufbauen können
Wie gesagt: Danke läuft super!
Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk

Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 20 Januar 2018, 12:12:13
Hallo,
habe mit dem passwortlosen ssh noch ein Problem. Habe folgendes gemacht:
Auf beiden Maschinen gibt es user fhem in der Gruppe dialout. Erst einmal können sich auf beiden Maschinen der Nutzer fhem einloggen.
Das home-Verzeichnis für fhem habe ich auf  /home/fhem gesetzt.
Jeweils darunter ein .ssh - Verzeichnis erzeugt.

Dann auf server 1 einen rsa - key generiert
ssh-keygen -t rsa -P ''
und den auf die Zielmaschine kopiert:
ssh-copy-id -i ~/.ssh/id_rsa.pub fhem@server2
Das alles unter dem user fhem.
Vorsichtshalber auf der Zielmaschine im .ssh - Verzeichnis
cp authorized_keys authorized_keys2
kopiert. Scheint wohl von der ssh - Version abhängen.
Trotzdem kommt die Passwortabrage bei
ssh fhem@server2

Habt ihr abweichend davon, noch etwas anderes gemacht? Bei mir im .ssh - Verzeichnis sind die beiden Dateien:
id_rsa.key und id_rsa.pub vorhanden.

Elektrolurch
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 21 Januar 2018, 15:57:17
Hallo,

jetzt wollte ich mit dem Befehl visudo bei den Benutzer-Priviligien hinter root die aus Beitrag 49 gepostete Zeile einfügen:
fhem ALL=(ALL) NOPASSWD:/bin/systemctl * homebridge


bekomme aber einen syntax Error, wobei ich den Grund nicht nachvollziehn kann oder stimmt die Position der Zeile nach root nicht?

P.S: ohne die neue Zeile kommt auch kein Syntaxfehler
Elektrolurch

Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 21 Januar 2018, 16:10:12
Welches System hast du?

Bei Stretch z.B. werden andere User (u.a. pi) per include eingebunden.

Das heisst in /etc/sudoers.d sind zusätzliche Dateien (eine pro User, d.h. für pi sollte schon eine da sein, die kann kopiert und angepsst werden).

Das gilt bzgl. pi usw. natürlich erst mal nur auf einem Raspberry PI ;)

Gruß, Joachim
Titel: Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RaspiLED am 21 Januar 2018, 17:22:05
Fyi:

fhem@fhem:~$ sudo cat /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL
fhem    ALL=(ALL:ALL) NOPASSWD:/bin/systemctl

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) NOPASSWD:ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d
fhem@fhem:~$ uname -a
Linux fhem 4.9.0-4-686-pae #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) i686 GNU/Linux




Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: eAntw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 22 Januar 2018, 11:14:47
Ok. Danke. So gehts:
fhem ALL=(ALL:ALL) NOPASSWD:/bin/systemctl

aber so gehts leider nicht (Beitrag #49)
fhem ALL=(ALL:ALL) NOPASSWD:/bin/systemctl * homebridge,openvpn

Dann bekomme ich den Syntaxfehler.
Muss das hinter dem NOPASSWD ev. dann in "" oder '' gesetzt werden?

Elektrolurch
Titel: Antw:eAntw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: no_Legend am 22 Januar 2018, 11:23:53
Zitat von: Elektrolurch am 22 Januar 2018, 11:14:47
Ok. Danke. So gehts:
fhem ALL=(ALL:ALL) NOPASSWD:/bin/systemctl

aber so gehts leider nicht (Beitrag #49)
fhem ALL=(ALL:ALL) NOPASSWD:/bin/systemctl * homebridge,openvpn

Dann bekomme ich den Syntaxfehler.
Muss das hinter dem NOPASSWD ev. dann in "" oder '' gesetzt werden?

Elektrolurch

Edit:
Warum gibst du FHEM nicht die kompletten systemctl frei?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: binford6000 am 05 Februar 2018, 13:09:00
Hi Dan,
ich habe dein Modul seit Beginn im Einsatz. Läuft prächtig!
Beim shutdown restart taucht immer folgende Meldung im Log auf:
2018.01.30 14:17:18 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_serviced.pm line 373.

Wie lange das schon so ist kann ich nicht sagen - hebe meine Logs nur 7 Tage auf.
VG Sebatsian
Titel: Antw:eAntw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 05 Februar 2018, 19:14:54
Zitat von: Elektrolurch am 22 Januar 2018, 11:14:47
Ok. Danke. So gehts:
fhem ALL=(ALL:ALL) NOPASSWD:/bin/systemctl

aber so gehts leider nicht (Beitrag #49)
fhem ALL=(ALL:ALL) NOPASSWD:/bin/systemctl * homebridge,openvpn

Dann bekomme ich den Syntaxfehler.
Muss das hinter dem NOPASSWD ev. dann in "" oder '' gesetzt werden?

Elektrolurch

Du musst leider immer den kompletten Pfad angeben, zumindest habe ich noch keine andere Lösung gefunden.
fhem ALL=(ALL:ALL) NOPASSWD:/bin/systemctl * homebridge,/bin/systemctl * openvpn


Zitat von: binford6000 am 05 Februar 2018, 13:09:00
Hi Dan,
ich habe dein Modul seit Beginn im Einsatz. Läuft prächtig!
Beim shutdown restart taucht immer folgende Meldung im Log auf:
2018.01.30 14:17:18 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_serviced.pm line 373.

Wie lange das schon so ist kann ich nicht sagen - hebe meine Logs nur 7 Tage auf.
VG Sebatsian

Das ist schon gefixt (bei mir).
Da es kein schwerwiegender Fehler ist habe ich die Version hier noch nicht aktualisiert.

Wenn ich die Tage Zeit dafür finde, checke ich das aktuelle Modul in SVN ein.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Wernieman am 06 Februar 2018, 14:19:46
Das Du den genauen Pfad angeben mußt ist ein Sicherheitsfeature. Stell Dir mal vor, Du hast ein "Tolles-Programm" und gibst dieses per sudo ohne Pfad frei. Jetzt kommt ein "Böser" (der sich einloggen kann) und nett sein "böses-Script" einfach  "Tolles-Programm". Wenn der Pfad nicht angegeben würde, könnte er damit sein Programm per sudo als root starten ...

Vergiss nicht, das Linux als Unix-System ein echtes  Multiuserbetriebsystem ist ...
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: simonTS am 13 November 2018, 22:56:39
Hallo,

ich habe mich gerade am modul versucht. Leider scheints bei mir zu hängen:

define SD_doorpi serviced doorpi pi@192.168.1.6
attr SD_doorpi serviceInitd 1


der manuelle login via ssh funktioniert, ebenso service doorpi status.
Die Statusabfrage via fhem/serviced führt leider zu einer ewig andauernden Abfrage. Dabei wird das statereading permanent mit "status" beschrieben. Zumindest aktualisiert sich der Timestamp permanent ...

Mein Log untenstehend. Dabei habe ich den schalter für initd zu zuerst nicht gesetzt gehabt, wovon die erste zeile zeugt. Allerdings zeigt es ebenso, dass der login schonmal funktioniert.

sudo: systemctl: command not found
2018.11.13 22:34:16 1: Timeout for serviced_ExecCmd reached, terminated process 27006
2018.11.13 22:34:16 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_serviced.pm line 373.
2018.11.13 22:35:18 1: Timeout for serviced_ExecCmd reached, terminated process 27122
2018.11.13 22:41:41 1: PERL WARNING: Subroutine serviced_Initialize redefined at ./FHEM/98_serviced.pm line 32.
2018.11.13 22:41:41 1: PERL WARNING: Subroutine serviced_Define redefined at ./FHEM/98_serviced.pm line 57.
2018.11.13 22:41:42 1: PERL WARNING: Subroutine serviced_Undef redefined at ./FHEM/98_serviced.pm line 93.
2018.11.13 22:41:42 1: PERL WARNING: Subroutine serviced_Shutdown redefined at ./FHEM/98_serviced.pm line 103.
2018.11.13 22:41:42 1: PERL WARNING: Subroutine serviced_shutdownwait redefined at ./FHEM/98_serviced.pm line 126.
2018.11.13 22:41:42 1: PERL WARNING: Subroutine serviced_Notify redefined at ./FHEM/98_serviced.pm line 154.
2018.11.13 22:41:42 1: PERL WARNING: Subroutine serviced_Get redefined at ./FHEM/98_serviced.pm line 192.
2018.11.13 22:41:42 1: PERL WARNING: Prototype after '@' for main::serviced_Set : $@;$ at ./FHEM/98_serviced.pm line 208.
2018.11.13 22:41:42 1: PERL WARNING: Prototype mismatch: sub main::serviced_Set ($@) vs ($@;$) at ./FHEM/98_serviced.pm line 256.
2018.11.13 22:41:42 1: PERL WARNING: Subroutine serviced_Set redefined at ./FHEM/98_serviced.pm line 209.
2018.11.13 22:41:42 1: PERL WARNING: Subroutine serviced_Attr redefined at ./FHEM/98_serviced.pm line 259.
2018.11.13 22:41:42 1: PERL WARNING: Subroutine serviced_ExecCmd redefined at ./FHEM/98_serviced.pm line 330.
2018.11.13 22:41:42 1: PERL WARNING: Subroutine serviced_ExecFinished redefined at ./FHEM/98_serviced.pm line 385.
2018.11.13 22:41:42 1: PERL WARNING: Subroutine serviced_GetUpdate redefined at ./FHEM/98_serviced.pm line 446.
2018.11.13 22:42:51 1: Timeout for serviced_ExecCmd reached, terminated process 27319
2018.11.13 22:42:51 1: PERL WARNING: Use of uninitialized value $string in split at ./FHEM/98_serviced.pm line 387.
2018.11.13 22:42:51 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/98_serviced.pm line 391.
2018.11.13 22:42:51 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4365.
2018.11.13 22:42:51 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/98_serviced.pm line 439.
2018.11.13 22:50:18 1: Timeout for serviced_ExecCmd reached, terminated process 27749


Vllt. ne idee, wo mein Fehler liegt?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Wernieman am 15 November 2018, 09:35:37
sudo: systemctl: command not found
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: simonTS am 16 November 2018, 23:42:47
Einen Schönen Guten Abend!

Leider nicht ... Die Zeile stammt noch von meinem ersten Versuch, bevor ich den switch auf initd gesetzt habe. Allerdings hat sich dennoch die Fehlermeldung geändert:

2018.11.16 23:39:03 5: Cmd: >get SD_doorpi status<
2018.11.16 23:39:03 4: SD_doorpi: executed shell command: sudo service doorpi status
2018.11.16 23:39:03 4: BlockingCall (serviced_ExecCmd): created child (1828), uses telnetPort to connect back
2018.11.16 23:39:03 5: Starting notify loop for SD_doorpi, 1 event(s), first is status
2018.11.16 23:39:03 5: createNotifyHash
sudo: Kein TTY vorhanden und kein »askpass«-Programm angegeben
2018.11.16 23:39:03 5: End notify loop for SD_doorpi
2018.11.16 23:39:03 4: WEB: /fhem?detail=SD_doorpi&dev.getSD_doorpi=SD_doorpi&cmd.getSD_doorpi=get&arg.getSD_doorpi=status&val.getSD_doorpi=&XHR=1&addLinks=1&fwcsrf=csrf_278740654645988&fw_id=5178 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.11.16 23:39:03 4: Connection accepted from telnetPort_127.0.0.1_50770
2018.11.16 23:39:03 5: Cmd: >{BlockingStart('2474')}<
2018.11.16 23:39:03 5: Cmd: >{serviced_ExecFinished('SD_doorpi|sudo: Kein TTY vorhanden und kein »askpass«-Programm angegeben|1')}<
2018.11.16 23:39:03 5: Starting notify loop for SD_doorpi, 2 event(s), first is error
vorhanden und kein »askpass«-Programm angegeben
2018.11.16 23:39:04 5: End notify loop for SD_doorpi
2018.11.16 23:39:04 3: SD_doorpi: Error: sudo: Kein TTY vorhanden und kein »askpass«-Programm angegeben


macht mich aber auch nicht schlauer. Eigentlich kann ich mich mit dem Nutzer Problemlos in beiden Systemen bewegen, bzw. mit pi auf dem remote system. Vllt suche ich aber auch an der falschen stelle.

EDIT:
Das lag jetzt schonmal am falschen eintrag in sudoers. Das Anpassen auf service hatte ich wohl auch vergessen. Leider dennoch kein erfolg. der manuelle weg via ssh geht inkl. sudo service ... ohne password problemlos.

Unit doorpi.service could not be found.
2018.11.16 23:50:29 3: SD_doorpi: Error: Unit doorpi.service could not be found.

Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 16 November 2018, 23:53:43
Hast du PASSWORTLOSEN Zugang für den User FHEM (nicht pi!) auf dem (Remote)system!?

Bzw. für User FHEM (nicht pi) sudo OHNE PASSWORT zumindest für den "service-Aufruf"!?

(bin grad nicht so sicher, ob du lokal oder remote ausführst/ausführen willst, weil du etwas von ssh schreibst)

Denn so wie es geschrieben steht: es wird nach einem Passwort bei ssh bzw. bei dem sudo "gefragt"...
...da fhem da automatisch nichts eingeben kann (eine Möglichkeit wäre das angemerkte "askpass" [Programm dass das automatisch tut] aber davon halte ich nichts!) schlägt der Aufruf fehl bzw. wird abgebrochen.

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: simonTS am 16 November 2018, 23:59:34
Da war ich wohl zu langsam ;-)

Ok. Das bedeutet ich muss auf dem remote system den nutzer fhem anlegen. das habe ich nicht gemacht.

lediglich der ssh pi@ip funktioniert ohne password, der sudo service ... wird dann logischerweise als pi ausgeführt, wenn ich es "von hand" versuche nachzustellen.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 17 November 2018, 00:29:50
Erst mal bevor etwas durcheinander geht:

wo läuft fhem?

wo willst du den Service starten etc.?

Selber PI oder auf einem anderen PI als dort wo fhem läuft?


Wenn selber PI: sudo OHNE Passwort für den User fhem für "Service-Befehl" einrichten

Wenn fhem auf einem anderen PI (Rechner) läuft als dort wo du den Service steuern willst: ssh-Login OHNE Passwort für User fhem einrichten
(hat nix mit dem Anlegen eines Users fhem auf dem Remote-System zu tun!!!)

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: simonTS am 17 November 2018, 08:36:44
Danke Dir!
Der Spruch, wer lesen kann ... gilt wohl auch für schreibende ;-) Mein Problem ist für mich natürlich klar.

Testweise habe ich den Dienst vom entfernten DoorPI abfragen wollen, weil er mir als erstes eingefallen ist. dabei läuft FHEM mit Benutzer fhem auf RPI A und DoorPi unter pi auf RPI B:

fhem@RPI A
--define SD_doorpi serviced doorpi pi@RPI A
----attr SD_doorpi serviceInitd 1
--sudoers: fhem ALL=(ALL) NOPASSWD:/usr/sbin/service

doorpi@RPI B
--sudo service doorpi status ist ohne PW möglich, da in sudoers eingetragen

RPI A kann sich ohne PW mit ssh pi@RPI B einloggen.

Das Log zeigt wie das Reading "error": Unit doorpi.service could not be found.

Die Version ist 1.2.0.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 17 November 2018, 09:21:43
Noch mal, in dem Fall lesen!

User fhem auf PI A braucht kein sudo für irgendwas!
Sondern PASSWORTLOSEN Login per ssh auf PI B als User pi, der dann dort (PI B) per sudo den Service steuert/abfrägt...

Dazu musst du ein Zertifikat erzeugen und dann auf den PI B übertragen...
Anleitungen dazu gibt es genug, z.B. http://heinz-otto.blogspot.com/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html

Sofern (was ich jetzt auswendig nicht weiß) das Fhem-Modul systemd einen Dienst remote steuern kann...


Wenn du dich direkt per ssh auf dem PI B (DoorPi) einloggst, als User pi und den Service-Befehl eingibst, geht es dann?

Welche Betriebssysteme laufen jeweils!?

Wie wird der DoorPi-Dienst auf PI B gestartet?

initd oder systemd!?

Und zum Testen/Ausprobieren macht es natürlich Sinn gleich mal den kompliziertesten Fall zu nehmen... ;)

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 17 November 2018, 09:29:16
ZitatRPI A kann sich ohne PW mit ssh pi@RPI B einloggen.

Welcher User!?

User pi auf RasPi A bei RasPi B ODER User fhem auf RasPi A als User pi auf RasPi B!?

Das ist die erste entscheidende Frage!
Und das muss gehen, da ja das fhem-Modul die Befehle als User fhem auf RasPi A absetzen soll.
Dazu muss sich User fhem (NICHT pi) passwortlos auf RasPi B (als User pi) einloggen können.

Ist das möglich muss eben der Service-Aufruf als User pi mit sudo auf RasPi B funktionieren...

Also immer langsan!
Lesen, denken, ausführen!

Sonst sind am Ende beide Systeme "Schrott"...

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: simonTS am 18 November 2018, 10:12:47
Hey Danke Euch!

Also, mit der Version 1.2.3 aus dem ersten Eintrag hier im Thema.
Zertifikat von RPI A bei RPI B hinterlegt -> passwortloser zugang fkt.

Eingeloggt auf RPI A als fhem kann ich ohne Passwort mit "ssh pi@RPI B" einloggen, hier direkt mit der Abfrage:

fhem@fhem:/opt/fhem $ ssh pi@192.168.1.6 sudo service doorpi status
DoorPi is running.


In fhem habe ich dem servicd das attribut für initd auf 1 gesetzt, da ja initd und nicht systemctl.

Und gerade nochmal im Log geschaut, dort überschlägt sich dann eine Abfrage nach der anderen wie:

2018.11.18 10:17:10 4: Connection accepted from telnetPort_127.0.0.1_58866
2018.11.18 10:17:10 5: Cmd: >{BlockingStart('3997')}<
2018.11.18 10:17:10 5: Cmd: >{serviced_ExecFinished('SD_doorpi||0')}<
2018.11.18 10:17:10 4: SD_doorpi: executed shell command: ssh pi@192.168.1.6 'sudo service doorpi status'
2018.11.18 10:17:10 4: BlockingCall (serviced_ExecCmd): created child (5743), uses telnetPort to connect back
2018.11.18 10:17:10 5: Starting notify loop for SD_doorpi, 1 event(s), first is status
2018.11.18 10:17:10 5: End notify loop for SD_doorpi
2018.11.18 10:17:11 4: Connection accepted from telnetPort_127.0.0.1_58870
2018.11.18 10:17:11 5: Cmd: >{BlockingStart('3998')}<
2018.11.18 10:17:11 5: Cmd: >{serviced_ExecFinished('SD_doorpi||0')}<
2018.11.18 10:17:11 4: SD_doorpi: executed shell command: ssh pi@192.168.1.6 'sudo service doorpi status'
2018.11.18 10:17:11 4: BlockingCall (serviced_ExecCmd): created child (5746), uses telnetPort to connect back
2018.11.18 10:17:11 5: Starting notify loop for SD_doorpi, 1 event(s), first is status



[EDIT]
Je länger ich darüber nachdenke ...
* Dazu muss sich User fhem (NICHT pi) passwortlos auf RasPi B (als User pi) einloggen können.
* wie meinst du das? ist das dann ein ssh fhem@RPI B oder ssh pi@RPI B ? Daher auch mal meine Frage, ob ich dann auf dem remote system auch den nutzer fhem anlegen muss, damit ein login ssh fhem@RPI B klappt. Der Nutzer fhem auf dem remote system ist nicht angelegt, der Nutzer fhem kann sich passwortlos als pi auf dem remote system anmelden.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: simonTS am 27 November 2018, 19:46:28
N'Abend,

ich weiß nicht, ob es sich gehört auf seine eigene Frage zu fragen ... Ich hoffe, daß ist ok.

Ich gebe es auf, möchte dennoch von meinem Versuch berichten. Also, was habe ich getan:

RPI_A: RPI3/Debian stretch@192.168.1.8: fhem, user=fhem
RPI_B: RPI3/Debian stretch@192.168.1.6: doorpi, user=pi

ssh key von RPI_A auf RPI_B kopiert:
fhem@fhem:~ $ cat .ssh/id_rsa.pub | ssh pi@192.168.1.6 'cat >> .ssh/authorized_keys'
--> passwortloser Zugang von RPI_A zu RPI_B via Zertifikat funktioniert.

visudo RPI_B:
fhem ALL=(ALL) NOPASSWD:/usr/sbin/service

fhem:
define T_SD_doorpi serviced doorpi pi@192.168.1.6
attr T_SD_doorpi serviceInitd 1
attr T_SD_doorpi serviceLogin serviceLogin pi@192.168.1.6
attr T_SD_doorpi serviceSudo 0 und 1 ausprobiert


was passiert bei einer manuellen Abfrage:

fhem@fhem:/opt/fhem $ ssh pi@192.168.1.6 'sudo service doorpi status'
DoorPi is running.

und ohne sudo:
fhem@fhem:/opt/fhem $ ssh pi@192.168.1.6 'service doorpi status'
bash: service: command not found


was bekomme ich als output im log:

2018.11.27 19:40:02 5: End notify loop for SD_doorpi
2018.11.27 19:40:02 4: Connection accepted from telnetPort_127.0.0.1_35842
2018.11.27 19:40:02 5: Cmd: >{BlockingRegisterTelnet($cl,8997)}<
2018.11.27 19:40:02 5: SD_doorpi: serviced_ExecCmd com: ssh pi@192.168.1.6 'sudo service doorpi status', line: 3
2018.11.27 19:40:02 5: Cmd: >{BlockingStart('8997')}<
2018.11.27 19:40:02 5: Cmd: >{serviced_ExecFinished('SD_doorpi|0|')}<
2018.11.27 19:40:02 5: SD_doorpi: serviced_Set executing shell command: ssh pi@192.168.1.6 'sudo service doorpi status'
2018.11.27 19:40:02 4: BlockingCall (serviced_ExecCmd): created child (12049), uses telnetPort to connect back
2018.11.27 19:40:02 5: Starting notify loop for SD_doorpi, 1 event(s), first is status
2018.11.27 19:40:02 5: createNotifyHash
2018.11.27 19:40:02 5: End notify loop for SD_doorpi
2018.11.27 19:40:02 4: Connection accepted from telnetPort_127.0.0.1_35846
2018.11.27 19:40:02 5: Cmd: >{BlockingRegisterTelnet($cl,8998)}<
2018.11.27 19:40:03 5: SD_doorpi: serviced_ExecCmd com: ssh pi@192.168.1.6 'sudo service doorpi status', line: 3
2018.11.27 19:40:03 5: Cmd: >{BlockingStart('8998')}<
2018.11.27 19:40:03 5: Cmd: >{serviced_ExecFinished('SD_doorpi|0|')}<
2018.11.27 19:40:03 5: SD_doorpi: serviced_Set executing shell command: ssh pi@192.168.1.6 'sudo service doorpi status'
2018.11.27 19:40:03 4: BlockingCall (serviced_ExecCmd): created child (12053), uses telnetPort to connect back
2018.11.27 19:40:03 5: Starting notify loop for SD_doorpi, 1 event(s), first is status
2018.11.27 19:40:03 4: DbLog DbLog_haus -> ################################################################
2018.11.27 19:40:03 4: DbLog DbLog_haus -> ###              start of new Logcycle                       ###
2018.11.27 19:40:03 4: DbLog DbLog_haus -> ################################################################
2018.11.27 19:40:03 4: DbLog DbLog_haus -> number of events received: 1 for device: SD_doorpi
2018.11.27 19:40:03 4: DbLog DbLog_haus -> check Device: SD_doorpi , Event: state: status
2018.11.27 19:40:03 5: End notify loop for SD_doorpi

...
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 27 November 2018, 20:01:26
Hallo simonTS,

ja und?

Geht oder geht nicht?

Aber es sind immer noch Verständnislücken sichtbar:

1. du loggst dich auf PI_B als User pi ein NICHT als User fhem! D.h. der Eintrag in der sudoers auf PI_B ist unnötig. (Klar das ssh-Kommando führt User fhem auf PI_A aus)

2. klar brauchst du sudo für Zugriff auf Service-Routinen! (egal als welcher User auf welchem "Rechner" auch immer / außer: eingeloggt als root)

3. was passiert, wenn du dich als User pi direkt auf PI_B einloggst (genau das macht nämlich dein: ssh pi@PI_B) und dann "sudo service doorpi status" o.ä. eingibst?

4. zum Übertragen von Zertifikaten für passwortlosen Zugang gibt es eine elegantere Variante: ssh-copy-id https://www.ssh.com/ssh/copy-id


Also du musst immer wissen welcher User du auf welcher Seite bist und welche Befehle du dann in wessen Kontext ausführst!
Ist nicht einfach aber da muss man einmal durch ansonsten wird es nicht klappen!

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 27 November 2018, 20:05:12
@simonTS:

Habe jetzt nicht alle zurückliegenden Beiträge von Dir gelesen.
Kann es sein dass der passwortlose Zugang nicht für den Benutzer eingerichtet ist unter dem FHEM läuft? Dieser benötigt nämlich die passwortlose Anmeldung zum RPI_B.
Falls FHEM unter dem user fhem läuft, dann den Ordner ~/.ssh nach /opt/fhem/.ssh kopieren, dann sollte auch der Zugang zu RPI_B aus FHEM heraus klappen.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: simonTS am 27 November 2018, 20:42:34
Hey!

Danke euch für das abendliche Interesse!! Da bin ich ja schon zu spät zurück am Rechner ;-)

@DeeSPe
FHEM läuft unter fhem auf RPI_A. Das Zertifikat habe ich als fhem erstellt. Muss ich auf dem remote, also RPI_B, auch fhem als user anlegen? der doorpi läuft auf dem remote RPI_B als pi?
Deswegen funktioniert ja auch von fhem@RPI_A$ ssh pi@RPI_B 'sudo service doorpi status'. Oder muss von fhem@RPI_A$ ssh fhem@RPI_B 'sudo service doorpi status' gehen?

@MadMax-FHEM
1. Das stimmt, ist mir jetzt auch aufgefallen. Das ist mir beim testen passiert, habe ich wohl vergessen zurückzustellen... -> wieder auf user 'pi ' gestellt, aber keine änderung
2. nur für den 'service ... status' doch nicht? aber habs ja in der sudoers eingetragen.
3. habe ich oben im Bsp. dort kommt ein 'Doorpi running.'
4. ;-) Danke!

Ja ja, der DAU sitzt gewöhnlich vor dem Monitor, ich weiß ;-) Wahrscheinlich sehe ich gerade vor lauter Bäumen den Wald nicht mehr ... Da die Klingel jetzt eh umzieht mache ich demnächst mal die VM platt und versuchs nochmal neu...

[EDIT]
Wenn ich den status via get Abfrage, scheint sich das Ding einfach in Schleife zudrehen... Es hängt nicht, gibt aber nicht auf abzufragen. Ich kann die prozesse killen oder das Modul löschen und neu anlegen, aber nichts mehr damit anfangen. Ich habe mir keinen Code angeschaut, aber ... Die Version aus dem 1. Thread ist doch korrekt?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 27 November 2018, 20:56:37
Nein ein User fhem auf PI_B ist unnötig bzw. macht das ganze noch komplizierter...

Wie geschrieben: in Ruhe überlegen welcher User auf welchem System WAS ausführt/ausführen soll...

Noch ausführlicher geht nicht mehr als in den letzten Antworten erläutert...

Wichtig ist in Ruhe drüber nachdenken...
Evtl. mal "aufzeichnen"...

Und erst wenn das klar ist: aktiv werden und Dinge einrichten.

EDIT: es fehlt auch noch die Info (oder ich hab es überlesen) was "sudo service doorpi status" (bzw. start/stop) auf PI_B mit User pi "sagt"...

EDIT2: den Link zu Otto's Blog hast du dir angeschaut? Da ist alles noch mal erläutert... Und wie ich finde sehr gut...

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 27 November 2018, 21:19:03
Ich versuch's doch noch mal (aber einfacher geht es wirklich nicht mehr)...
...siehe Anhang.

User fhem loggt sich "als User pi" auf PI_B ein.
Das ist: ssh pi@PI_B
Damit dazu kein Passwort eingegeben werden muss: Zertifikate von User fhem im Verzeichnis .ssh des Users pi  auf PI_B liegen (ssh-copy-id: .ssh Zertifikate des Users fhem auf PI_A nach .ssh des Users pi auf PI_B)
Somit wird dem User fhem "vertraut" auch ohne Passwort...

Alles weitere (also das an ssh User@RemoteHost Angehängte) wird dann "im Kontext" des Users "User auf RemoteHost" ausgeführt.
Hier also: User pi auf PI_B...

Konkret: das Kommando "sudo service doorpi status" wird dann "als User pi" auf PI_B ausgeführt.
sudo deshalb weil für den Aufruf "service Name status|start|stop|restart" eben nur der User root Berechtigung hat.
Damit da dann kein Passwort gebraucht wird muss für den User pi auf PI_B in der sudoers mindestens für dieses Kommando ein "NO_PASSWD" Eintrag vorhanden sein.

Das war's...

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: simonTS am 27 November 2018, 21:25:15
user fhem auf RPI_B ist unnötig -> Danke! War für mich der schwierigste Teil und auch Dott sei Dank der sinnfreiste ...

Nach erfolgreicher Medi(t)ation habe ich das eigentlich unter der Prämisse oben mit den richtigen Nutzern eingerichtet. An der Stelle geht es mir genauso, ich weiß nicht, ob ich mich mitteilen kann. fhem@PC1 loggt sich auf pi@PC2 ein und frägt einen Dienst ab, soweit eine einfache - und im Beispiel funktionierende - Geschichte.

Auch Otto's Blog nochmal nach Abweichung durchforstet ... Entspricht prinzipiell meiner Vorgehensewiese

UND der Login funktioniert...:

fhem@fhem:/opt/fhem $ ssh pi@192.168.1.6 'sudo service doorpi status'
DoorPi is running.

und ohne sudo:
fhem@fhem:/opt/fhem $ ssh pi@192.168.1.6 'service doorpi status'
bash: service: command not found


Nix für Ungut. Ich finde es einfach nicht und es scheint ein einfacher Fehler (des DAU!!!) zu sein. Ich gehe nochmal in mich und berichte nach Aufbau aus greenfield nochmal ....

[EDIT]
@JOACHIM, genauso hab ich es ja! Und das läuft trotzdem in Schleife ... Vllt. habe ich was anderes verhauen. Ich setze nochmal neu auf.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 27 November 2018, 21:28:15
Noch mal (also ich sehe an deiner geposteten Ausgabe keinen Fehler): geht es nicht?

Und wenn WAS genau geht nicht?

Hast du das Serviced-Device richtig konfiguriert?

Poste doch mal ein list (auch wenn schon geschehen, dann brauche ich nicht lang suchen)...

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: simonTS am 27 November 2018, 21:33:01
Nein, leider geht es nur via CLI, nicht in fhem.

wenn ich das device wie unten anlege und ein 'get SD_doorpi status' aus der fhem WEB oberfläche absetze bekomme ich im reading 'state status 2018-11-27 21:32:34' lediglich die sekunden hochgezählt.


Internals:
   CFGFN     
   DEF        doorpi pi@192.168.1.6
   NAME       SD_doorpi
   NOTIFYDEV  global
   NR         4194
   NTFY_ORDER 50-SD_doorpi
   SERVICENAME doorpi
   STATE      Initialized
   TYPE       serviced
   VERSION    1.2.3
   READINGS:
     2018-11-27 21:29:56   state           Initialized
   helper:
Attributes:
   alias      Service doorpi
   cmdIcon    restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY
   devStateIcon Initialized|status:light_question error|failed:light_exclamation running:audio_play:stop stopped:audio_stop:start stopping:audio_stop .*starting:audio_repeat
   icon       hue_room_garage
   room       Services
   serviceInitd 1
   serviceLogin pi@192.168.1.6
   serviceSudo 1
   webCmd     start:restart:stop:status


-> Also, es zeigt den status nicht an und frägt in schleife ab. Das geht nicht.
-> Es müsste doch ein Reading mit state running oder so rauskommen?

Und ab dann nur noch

Work already/still in progress... Please wait for the current process to finish.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: MadMax-FHEM am 27 November 2018, 22:08:53
Hmm, also ich hab das grad mal nachgespielt...
...funktioniert einwandfrei.

Ich habe einfach mal den BlueTooth Service auf einem remoten System per serviced Modul gesteuert bzw. abgefragt.

Irgendwas scheint bei dir eigenartig zu sein...

Ich konnte jetzt auch nichts an der Modul-Definition finden...

Du kannst das auch mal manuell nachspielen (hast du das schon?):

ssh pi@192.168.1.6 'sudo service doorpi status'

als User fhem in der Console ausführen...

Läuft fhem tatsächlich unter dem User fhem?

Wie wird fhem bei dir gestartet?
initd/systemd?

Poste doch mal den Inhalt des Startscripts...

Bin etwas ratlos weil bei mir ging das jetzt innerhalb von 5min...

EDIT: noch ein Test mit einem fhem auf einem anderen Rechner... Ebenfalls ok...

Gruß, Joachim
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Gisbert am 23 Dezember 2018, 14:15:36
Hallo DeeSPe,

kannst du mal nach dieser Auffälligkeit Ausschau halten?
https://forum.fhem.de/index.php/topic,93050.msg875815.html#msg875815 (https://forum.fhem.de/index.php/topic,93050.msg875815.html#msg875815)

Zitat von: Gisbert am 23 Dezember 2018, 13:58:29
Hallo Heiko,

kannst du eventuell der folgende Auffälligkeit (Fehler möchte ich es noch nicht nennen, da die Ursache auch bei mir liegen könnte) nachgehen?

Wenn man die Konfigurationsdateien mit "rereadcfg" in der Fhem-Kommandozeile einliest, dann stoppt das Modul serviced den Linux-watchdog, startet ihn aber nicht nach Ablauf der Zeit "serviceAutostart" neu. Da der Befehl "rereadcfg" vermutlich häufig im Umlauf ist, hat man danach den watchdog nicht mehr laufen.

Was macht "rereadcfg" genau? Offensichtlich was anderes, als Fhem zu stoppen und neu zu starten.

Viele Grüße Gisbert

Edit:
Mit "Shutdown Restart" in der Fhem-Kommandozeile erhält man das erwartete Verhalten, d.h. der watchdog wird beendet und nach dem Neustart von Fhem nach Ablauf der Zeit "serviceAutostart" wieder gestartet.

Edit2: Ich hab das Verhalten auch in den Beitrag "Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern" verlinkt.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: slor am 08 Januar 2019, 16:58:47
Hallo zusammen, gibt es schon Pläne das Module offizell einzuchecken?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Amenophis86 am 07 Februar 2019, 21:01:16
Wollte heute apache2 mit dem Modul überwachen bekomme als Status aber folgendes:

status Drop-In: /lib/systemd/system/apache2.service.d

In sudoers wurde apache2 eingefügt.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 08 Februar 2019, 13:57:54
Zitat von: Amenophis86 am 07 Februar 2019, 21:01:16
Wollte heute apache2 mit dem Modul überwachen bekomme als Status aber folgendes:

status Drop-In: /lib/systemd/system/apache2.service.d

In sudoers wurde apache2 eingefügt.

Wie ist denn die Ausgabe von
sudo systemctl status apache2
wenn Du es auf der Console ausführst?

Steht der Status in einer anderen Zeile als in der dritten? Dann kannst Du das über "attr <name> serviceStatusLine" anpassen.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 08 Februar 2019, 14:17:55
Zitat von: slor am 08 Januar 2019, 16:58:47
Hallo zusammen, gibt es schon Pläne das Module offizell einzuchecken?

Werde es die Tage mal einchecken wenn ich dazu komme.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Amenophis86 am 09 Februar 2019, 08:10:06
Zitat von: DeeSPe am 08 Februar 2019, 13:57:54
Steht der Status in einer anderen Zeile als in der dritten? Dann kannst Du das über "attr <name> serviceStatusLine" anpassen.

Oh man sry, hab nicht dran gedacht. Dachte das wäre ne Fehlerauswertung vom Modul. War in Zeile 5 jetzt klappt es. Danke
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 18 Februar 2019, 23:45:24
Habe das Modul soeben in's SVN eingecheckt.
Ab morgen früh dann im offiziellem Update.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: piet_pit am 24 Juni 2019, 15:16:00
Hallo Zusammen,
ich nutze das Modul seit einiger Zeit, vielen Dank dafür.

Ich habe folgende Frage...

Wenn ich in FHEM neue Devices für Homekit anlege, stoppe ich im Nachgang immer die homebridge (indem ich über SSH auf den RPi gehe), und starte dann neu, somit werden neue Devices eingelesen und sind dann im Homekit verfügbar.
Klappt das auch, wenn ich den Server über die Weboberfläche stoppe und neu starte, bei mir zumindest nicht..?

Evtl. stimmt mit meiner sudoers-Datei irgendetwas nicht, wie muss die angepasst werden, ich glaube meine Einträge sind da nicht vollständig.
Vielen Dank für die Unterstützung und viele Grüße
Pit
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 24 Juni 2019, 15:32:13
Zitat von: piet_pit am 24 Juni 2019, 15:16:00
Wenn ich in FHEM neue Devices für Homekit anlege, stoppe ich im Nachgang immer die homebridge (indem ich über SSH auf den RPi gehe), und starte dann neu, somit werden neue Devices eingelesen und sind dann im Homekit verfügbar.
Klappt das auch, wenn ich den Server über die Weboberfläche stoppe und neu starte, bei mir zumindest nicht..?

Genau dieses Szenario war mein Ursprung für die Entwicklung dieses Moduls.
Wenn ich nun eine Änderung an der Homebridge Konfiguration mache setze ich danach in FHEM ein "set homebridge restart" ab und damit wird dann Homebridge neu gestartet und somit die Konfiguration neu eingelesen.
Das steht in meiner sudoers:
fhem    ALL=(ALL) NOPASSWD:/bin/systemctl

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: piet_pit am 24 Juni 2019, 15:42:16
Hallo Dan,

vielen Dank für die Info, ich probiere das nachher einmal aus und melde mich danach.
VG
Pit
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: piet_pit am 24 Juni 2019, 16:05:32
Hallo Dan,

im Logfile auf dem "Homebridge-RPi steht nichts davon, dass der Service gestoppt und gestartet wurde, nur im Reading wird das angezeigt und aktualisiert. Mein FHEM läuft auf einem zweiten RPi, kann das daran liegen?
Wenn ich auf dem "Homebridge-RPi" gehe und dort alles "normal" eingebe, klappt es einwandfrei, evtl. muss ich ja noch Einträge auf dem FHEM-RPi in der sudoers vornehmen.

Vielen Dank und viele Grüße
Pit
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 24 Juni 2019, 16:11:51
Auf dem RPi mit Deinem FHEM hast Du also einen passwortlosen Zugang zu dem Homebridge-RPi eingerichtet, richtig?
Der Benutzer, über den Du die passwortlose Anmeldung eingerichtet hast (pi?), muss auch in die sudoers auf dem Homebridge-RPi.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: piet_pit am 24 Juni 2019, 17:38:35
Hallo Dan,
das klappt jetzt soweit, starten und stoppen via Serviced und man kann im Eve-Modul das zus. Device sehen. Im Log des ,,homebridge-RPi" ist aber nichts zu sehen von diesem Start/ Stop Vorgang, ist aber vielleicht so.
Danke nochmals für die Hilfe.
Viele Grüße
Pit
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: dennisk am 16 November 2019, 09:10:44
Hallo @DeeSPe,

vielen Dank für Dein sehr praktisches Modul!
Ich habe aber einen kleinen Fehler gefunden:
In Zeile 152 lautet der Code: my $sudo = AttrNum($name,"serviceSudo",1) || $login !~ /^root@/ ? "sudo " : "";
Damit funktioniert die Verwendung ohne sudo nicht, trotz gesetztem Attribut serviceSudo.
Nach minimaler Änderung der Zeile: my $sudo = AttrNum($name,"serviceSudo",1) || $login =~ /^root@/ ? "sudo " : "";
funktioniert das Modul auch ohne sudo. Aus meiner Sicht schlüssig, da die Überprüfung im ternären Operator nur dann sudo ergeben müsste, wenn $login root enthält.

Vielen Dank schon mal!
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 16 November 2019, 11:42:36
Zitat von: dennisk am 16 November 2019, 09:10:44
Hallo @DeeSPe,

vielen Dank für Dein sehr praktisches Modul!
Ich habe aber einen kleinen Fehler gefunden:
In Zeile 152 lautet der Code: my $sudo = AttrNum($name,"serviceSudo",1) || $login !~ /^root@/ ? "sudo " : "";
Damit funktioniert die Verwendung ohne sudo nicht, trotz gesetztem Attribut serviceSudo.
Nach minimaler Änderung der Zeile: my $sudo = AttrNum($name,"serviceSudo",1) || $login =~ /^root@/ ? "sudo " : "";
funktioniert das Modul auch ohne sudo. Aus meiner Sicht schlüssig, da die Überprüfung im ternären Operator nur dann sudo ergeben müsste, wenn $login root enthält.

Vielen Dank schon mal!

Vielen Dank für den Hinweis dennisk.
Du hast natürlich Recht, das ist mir und offensichtlich niemand anders bisher ausgefallen.
Habe es soeben geändert und als v1.2.5 in SVN eingecheckt.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 16 November 2019, 19:46:26
Zitat von: dennisk am 16 November 2019, 09:10:44
Hallo @DeeSPe,

vielen Dank für Dein sehr praktisches Modul!
Ich habe aber einen kleinen Fehler gefunden:
In Zeile 152 lautet der Code: my $sudo = AttrNum($name,"serviceSudo",1) || $login !~ /^root@/ ? "sudo " : "";
Damit funktioniert die Verwendung ohne sudo nicht, trotz gesetztem Attribut serviceSudo.
Nach minimaler Änderung der Zeile: my $sudo = AttrNum($name,"serviceSudo",1) || $login =~ /^root@/ ? "sudo " : "";
funktioniert das Modul auch ohne sudo. Aus meiner Sicht schlüssig, da die Überprüfung im ternären Operator nur dann sudo ergeben müsste, wenn $login root enthält.

Vielen Dank schon mal!

Irgendwie war ich heute früh noch nicht ganz wach und habe mich irgendwie von Deinem Argument täuschen lassen.
Es war schon richtig so wie es vorher (ohne Deine Änderung) war. Wenn Du schon root bist, benötigst Du doch kein sudo. Es wird nur benötigt wenn man eben kein root ist.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: dennisk am 17 November 2019, 09:46:05
OK, stimmt, wenn ich jetzt drüber nachdenke, hast Du natürlich Recht, sorry
Dennoch funktioniert bei mir die Nutzung ohne sudo wirklich nur mit der Änderung. Mein FHEM wird jedenfalls nicht unter root gestartet, sondern dem User fhem. Müsste dann nicht eigentlich, bei Setzen von serviceSudo = 0 kein sudo verwendet werden?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 17 November 2019, 13:31:56
Mir ist zwar noch nicht ganz klar warum man als Nicht-root kein sudo benötigen sollte, aber ich denke wenn Du nach Zeile 152 die folgende Zeile einfügst sollte es mit "serviceSudo 0" klappen.
$sudo = "" if (AttrNum($name,"serviceSudo",1) == 0);

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: dennisk am 18 November 2019, 19:51:23
Ich kann auf sudo verzichten, weil ich dem Benutzer fhem die Berechtigung erteilt habe, den systemd-Service zu steuern.
Das Ganze habe ich mit Polkit umgesetzt und verwende folgende Regel:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units") {
        if (action.lookup("unit") == "fhem.service") {
            var verb = action.lookup("verb");
            if (verb == "start" || verb == "stop" || verb == "restart") {
                if (subject.user == "fhem") {
                    return polkit.Result.YES;
                }
            }
        }
    }
});


Wie wäre alternativ folgende Anpassung: my $sudo = AttrNum($name,"serviceSudo",1) && $login !~ /^root@/ ? "sudo " : "";
Nun wird sudo nur dann verwendet, wenn der Parameter serviceSudo auf 1 steht UND der Benutzername nicht root ist. Jetzt müsste doch die ursprüngliche Funktionalität erhalten bleiben und serviceSudo = 0 funktioniert auch. Was denkst Du?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 18 November 2019, 21:25:01
Zitat von: dennisk am 18 November 2019, 19:51:23
my $sudo = AttrNum($name,"serviceSudo",1) && $login !~ /^root@/ ? "sudo " : "";

Danke.
Ist so eingecheckt!

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: piet_pit am 13 Juni 2020, 18:24:21
Hallo Dan,

ich nutze dein Tool und bin damit sehr zufrieden. Es erleichtert sehr den Umgang mit der Neukonfiguration z.B. bei Homebridge.

Nun habe ich homebridge neu installiert und bin dabei nach der Anleitung aus den github zu homebridge vorgegangen.

https://github.com/homebridge/homebridge/wiki/Install-Homebridge-on-Raspbian (https://github.com/homebridge/homebridge/wiki/Install-Homebridge-on-Raspbian)

Das hat sehr gut und einwandfrei geklappt, auch die Installation mit dieser

Homebridge Config UI X

Nun klappt aber dein Modul nicht mehr, deshalb die Frage, ob und wo ich das anpassen muss, da steige ich irgendwie nicht durch... 8)

Vielen Dank und viele Grüße
Pit




Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 26 Juni 2020, 11:47:30
Hallo Pit,

ich habe meinen homebridge Service schon ewig laufen und auch über das Modul serviced an FHEM angebunden.
Laut dem von Dir verlinktem Wiki sollte das ja weiterhin über homeridge.service laufen. Allerdings wird der Service nun nicht mehr über systemctl gesteuert, sondern über ein eigenes Kommando "hb-service". Ich habe keinerlei Ahnung was das nun anders macht.
Aber letztendlich ist homebridge-config-ui-x auch nur ein Plugin für homebridge.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: piet_pit am 29 Juni 2020, 17:27:42
Hallo Dan,

vielen Dank für deine Antwort.
Ich habe dein Modul deinstalliert und neu installiert, jetzt klappt es einwandfrei.

Viele Grüße
Pit
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Karflyer am 28 Oktober 2020, 15:45:09
Hallo Dan,

ich nutze an dem 'entfernten', zu steuernden Rechner einen anderen SSH-Port als den Standardport (22). Wie kann ich das bei der Definition des Devices angeben?

Eine weitere Frage. Wie muss die Definition des Devices aussehen um einen 'entfernten' Rechner neu zu booten (reboot bzw. shutdown restart)?

Grüße
Stefan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 05 Februar 2021, 12:18:54
Hallo,

ich brauche mal Unterstützung, da ich den Fehler nicht finde.
Situation:
Ich habe meinen zweiten Server "Kellergeist" neu aufgesetzt.
Von meinem ersten server aus habe ich per serviced vier Dienste kontrolliert. Alle 4 funktionierten, nach dem ich den "Kellergeist" neu eingerichtet habe, gehen nur noch zwei einwandfrei.
Daraus folgt:
a) An dem passwortlosen Zugriff über ssh auf "Kellergeist" kann es nicht liegen, dann würden ja alle vier Dienste nicht über fhem (serviced -> systemctl) kontrollierbar sein.
b) In der /etc/sudoers ist folgendes für den remote - Zugriff Nutzer fhem eingetragen:

fhem ALL=(ALL:ALL) NOPASSWD:/bin/systemctl


Für den Dienst "openvpn" bekomme ich folgende Fehlermeldung in fhem:

DEF openvpn fhem@Kellergeist
NAME openvpn
NOTIFYDEV global
SERVICENAME openvpn
STATE error
TYPE serviced
VERSION 1.2.5
Readings
error Unit openvpn.service could not be found. 2021-02-03 10:50:43
state error 2021-02-03 10:50:43


Wenn ich aber mich auf "Kellergeist" als Nutzer fhem anmelde, kann ich jeden Dienst mit

sudo systemctl restart openvpn

starten / stoppen oder restarten, ohne dass ein Passwort abgefragt wird.
Also stimmt der Eintrag in der /etc/sudoers wohl auch.
Für den zweiten Dienst (eine Instanz von fhem für kleinere andere Aufgaben auf Kellergeist) sieht es so aus:

   DEF        fhem fhem@Kellergeist
   NAME       fhem
   SERVICENAME fhem
   STATE      error
   TYPE       serviced
   VERSION    1.2.5
   READINGS:
     2021-02-01 13:14:03   error           sudo: no tty present and no askpass program specified
     2021-02-01 13:14:03   state           error
     2019-11-19 12:18:17   status          Active: active (running) since Tue 2019-11-19 12:17:38

Die Fehlermeldungen für "openvpn" (service kann nicht gefunden werden) und fhem (sudo: no tty present and no askpass program specified) sind auch noch unterschiedlich.verst
Die Probleme traten mit den zwei Diensten "openvpn" und "fhem" erst auf, nach dem der Server "Kellergeist" neu aufgesetzt wurde und jetzt unter buster läuft.

Jemand einen Tipp??
Wäre sehr dankbar.

Elektrolurch
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Otto123 am 05 Februar 2021, 12:50:34
Hi,

ich kenne das Modul nicht, aber um deine Aussage a) zu prüfen ein einfacher Test aus der FHEM Kommandozeile:
{qx(ssh fhem\@Kellergeist sudo whoami)}
{qx(ssh fhem\@Kellergeist whoami)}


Gruß Otto
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 05 Februar 2021, 13:03:14
Hallo Otto,

mit whoamI kommt natürlich:
sudo: no tty present and no askpass program specified
weil in der sudoers für fhem nur /bin/systemctl ohne passwort eingetragen ist.

{qx(ssh fhem\@Kellergeist sudo systemctl restart homebridge)}

geht natürlich.
Für "openvpn" oder "fhem" geht es, wie oben beschrieben, natürlich nicht.

Elektrolurch
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Otto123 am 05 Februar 2021, 13:17:07
Klingt nach: beide Dienst sind keine systemd Dienste sondern nach anderem Muster gestrickt?
{qx(ssh fhem\@Kellergeist ls -lha /etc/systemd/system/open*)}
{qx(ssh fhem\@Kellergeist ls -lha /etc/systemd/system/)}
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 06 Februar 2021, 10:02:35
Hallo Otto,

der fhem-service existiert unter /etc/systemd/system:
2021.02.06 09:52:01 1: -rw-rw---- 1 root root 455 Jan  2  2020 /etc/systemd/system/fhem.service

openvpn lässt sich zwar mit

sudo systemctl restart openvpn

starten, liegt aber nicht unter systemd/system
sondern unter /etc/init.d/openvpn.
Möglicherweise muss ich dass in der sudoers für fhem berücksichtigen?
Der Aufruf von sudo systemctl restart openvpn geht wohl dann weiter an service openvpn restart, und dass fehlt dann wohl in der sudoers.

So ganz verstehe ich das allerdings noch nicht.

Elektrolurch
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Otto123 am 06 Februar 2021, 13:48:27
Hi,

das mit service vermute ich auch, den Unterschied zu fhem.service versteh ich noch nicht.

Ich habe mir mal folgendes notiert (https://heinz-otto.blogspot.com/2017/08/raspberry-ausschalten-mit-fhem.html):
Inhalt der sudoers Datei
Die durch Komma getrennten Werte in der Datei haben folgende Bedeutung und benötigen immer den vollen Pfad!

/usr/sbin -> für alles im Verzeichnis
/usr/sbin/service * -> für alle Parameter
/usr/sbin/service apache2 * -> für alle weiteren Parameter
/usr/sbin/service apache2 reload -> genau nur hierfür

Insofern würde der jetzige Eintrag sowieso nicht komplett sein?

Gruß Otto
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 07 Februar 2021, 11:53:22
Hallo,


Cmnd_Alias FHEM_CMDS = /bin/systemctl *, /usr/sbin/service *

Damit klappt der remote - start von fhem.

Bei openvpn haben sich die Start-Skripte geändert:

Server:
• Place your server configuration file in /etc/openvpn/server
• Use the openvpn-server@.service like so:
$ sudo systemctl start openvpn-server@{Server-config}
Replace {Server-config} with the name of your config file without the .conf


Note:
• openvpn@.service is deprecated.
• openvpn.service is obsoleted. (This is only used for backward compatibility)


Wenn ich mich nun auf dem Server als fhem anmelde und folgendes eingebe:

ssh fhem@Kellergeist sudo systemctl start openvpn-server@server

klappt das ohne Probleme

Aber mit dem serviced - Opbjekt in fhem nicht:

set openvpn start

kommt im log:
error           sudo: Kein TTY vorhanden und kein »askpass«-Programm angegeben

Merkwürdig: Der Server, auf dem fhem und damit serviced läuft, ist auf deutsch eingestellt.
Der, auf dem openvpn-server läuft, auf englisch.
Da der ssh - Befehl solo (s.o.) funktioniert, aber nicht von fhem aus....
[gelöst]
Das Modul hat mit dem @server ein Problem, so dass kein login auf dem remote - Server erfolgt, d.h. das fhem@Kellergeist in der def wird ignoriert.
Lögung:
Attribut serviceLogin mit fhem@Kellergeist
setzen.

Elektrolurch

Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Otto123 am 07 Februar 2021, 12:17:39
Moin,

das @ kann ein Problem sein: openvpn-server@server
Wie gesagt ich kenne das Modul nicht, ich habe noch noch nicht ganz verstanden was Du konfiguriert hast, aber es kann sein das Du das @ schützen musst: \@

Gruß Otto
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Karflyer am 16 Februar 2021, 11:43:08
Ich hatte die Frage schon einmal gestellt aber leider keine Antwort erhalten.
Ich möchte mit dem Modul den Dienst auf einem entfernten Pi steuern. Dieser PI ist aber nicht über den Standard SSH-Port (22) erreichbar, sondern über einen anderen Port. Wie kann ich das in der Definition des Devices mitgeben?

Dan, wenn das nicht vorgesehen ist, könntest du es implementieren?

Grüße
Stefan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Otto123 am 16 Februar 2021, 12:20:16
Hallo Stefan,

unabhängig davon ob Dan eine Idee hat, lese ich das Handbuch von ssh so:
Zitat-p port
Port to connect to on the remote host. This can be specified on a per-host basis in the configuration file.

Wenn das in der DEF also nicht akzeptiert wird:
Zitat-F configfile
Specifies an alternative per-user configuration file. If a configuration file is given on the command line, the system-wide configuration file (/etc/ssh/ssh_config) will be ignored. The default for the per-user configuration file is ~/.ssh/config.
Sollte es doch machbar sein? Ich habe es aber nicht probiert

Für fhem liegt liegt das unter /opt/fhem/.ssh/config

Gruß Otto
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 16 Februar 2021, 13:20:05
Wie Otto schon geschrieben hat, sollte das sollte mit der config Datei funktionieren.

Ich gucke mir aber gerade das Modul an und schaue ob ich es noch mit übergeben bekomme.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Karflyer am 16 Februar 2021, 13:24:20
ZitatHallo Stefan,

unabhängig davon ob Dan eine Idee hat, lese ich das Handbuch von ssh so:
Zitat
-p port
Port to connect to on the remote host. This can be specified on a per-host basis in the configuration file.

Wenn das in der DEF also nicht akzeptiert wird:
Zitat
-F configfile
Specifies an alternative per-user configuration file. If a configuration file is given on the command line, the system-wide configuration file (/etc/ssh/ssh_config) will be ignored. The default for the per-user configuration file is ~/.ssh/config.
Sollte es doch machbar sein? Ich habe es aber nicht probiert

Für fhem liegt liegt das unter /opt/fhem/.ssh/config

Gruß Otto

Hallo Otto,

Ich habe im Code des Moduls nachgeschaut. In der def kann man offensichtlich den Port nicht angeben.

Dein zweiter Hinweis auf den config-file im ssh-Verzeichnis hat jedoch zum Erfolg geführt. Diese Möglichkeit kannte ich offen gestanden nicht. Vielen Dank dafür. Trotzdem käme es der Flexibilität des Moduls zugute, wenn Dan die Möglichkeit einer Portangabe vorsehen würde.

Grüße
Stefan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Karflyer am 16 Februar 2021, 13:32:04
Hallo Dan,
ZitatWie Otto schon geschrieben hat, sollte das sollte mit der config Datei funktionieren.
Ich gucke mir aber gerade das Modul an und schaue ob ich es noch mit übergeben bekomme.
Gruß
Dan

Beim überfliegen deines Codes habe ich 'quick and dirty' bei der Definition der Variable $login den Port übergeben. Ich habe den Port hierbei über ein Attribut  vorgegeben:
  my $sshPort = AttrVal($name,"serviceSSH-Port","");
  my $login = "-p ".$sshPort." ".AttrVal($name,"serviceLogin","");


Wäre vielleicht eine Möglichkeit, wenn du die def nicht anfassen möchtest.

Grüße
Stefan

Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 16 Februar 2021, 13:36:39
In der angehängten Version kann nun beim define nach IP/DNS die Erweiterung " -p <port>" angehängt werden, oder nachträglich im Attribut serviceLogin hinterlegt werden.
Das dürfte die config Datei hierfür überflüssig machen.
Bitte gerne testen und Feedback geben.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Karflyer am 16 Februar 2021, 14:39:55
ZitatIn der angehängten Version kann nun beim define nach IP/DNS die Erweiterung " -p <port>" angehängt werden, oder nachträglich im Attribut serviceLogin hinterlegt werden.
Das dürfte die config Datei hierfür überflüssig machen.
Bitte gerne testen und Feedback geben.

Die def sieht bei mir jetzt so aus:
define <name> serviced <Dienst Name> <user@ip-adresse> <-p Portnummer>

Das Modul akzeptiert die Definition stellt aber keine Verbindung her. Beim ssh-Aufruf wird nach wie vor der Standardport (22) genutzt:
ssh: connect to host 192.168.2.8 port 22: Connection refused

Ursache ist, das dass Attribut 'serviceLogin' den Port aus der def nicht bekommt. Erst nach Änderung dieses Attributs mit Angabe des Ports funktioniert es jetzt.

Grüße
Stefan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 16 Februar 2021, 15:59:25
Hab eine neue Version gebaut.
servicePort ist nun als Attribut verfügbar.
Übergeben kann man den Port beim Definieren nun ohne das "-p" dazwischen (das war irgendwie verwirrend), also:
define <name> serviced <service name> [user@ip-address] [port]

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Karflyer am 16 Februar 2021, 19:46:03
ZitatHab eine neue Version gebaut.
servicePort ist nun als Attribut verfügbar.
Übergeben kann man den Port beim Definieren nun ohne das "-p" dazwischen (das war irgendwie verwirrend), also:
Code: [Auswählen]
define <name> serviced <service name> [user@ip-address] [port]

Gruß
Dan

Funktioniert jetzt einwandfrei. Vielen Dank Dan für die rasche Umsetzung.

Grüße
Stefan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 16 Februar 2021, 20:33:02
Das freut mich.
Habe dabei sogar noch einen "Käfer festgesetzt" (bug fixed).
Ich checke die Version dann nachher noch ein damit sie ab morgen früh mit im Update ist.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: dennisk am 21 Februar 2021, 15:04:35
Hallo DeeSPe,

mir ist gerade beim Update aufgefallen, dass nach Deinen Änderungen serviceSudo beim Start von fhem als 1 gesetzt wird, obwohl bei mir das Attribut mit 0 eingetragen ist. Ich bin leider in Perl nicht so tief drin und konnte bisher noch nicht nachvollziehen, warum das auf Grund Deiner letzten Änderungen so ist. Könntest Du Dir das einmal anschauen? Wenn Du noch weitere Angaben brauchst, melde Dich.
Danke schon mal!
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 21 Februar 2021, 19:05:24
Zitat von: dennisk am 21 Februar 2021, 15:04:35
Hallo DeeSPe,

mir ist gerade beim Update aufgefallen, dass nach Deinen Änderungen serviceSudo beim Start von fhem als 1 gesetzt wird, obwohl bei mir das Attribut mit 0 eingetragen ist. Ich bin leider in Perl nicht so tief drin und konnte bisher noch nicht nachvollziehen, warum das auf Grund Deiner letzten Änderungen so ist. Könntest Du Dir das einmal anschauen? Wenn Du noch weitere Angaben brauchst, melde Dich.
Danke schon mal!

Hallo dennisk,

ich habe in den letzten Tagen öfter neu gestartet und konnte/kann das Verhalten nicht nachvollziehen. An dem "sudo" war ich auch gar nicht dran.
Hast Du ein paar mehr Informationen für mich? Was ist das für ein Dienst? Remote oder lokal? Zeig mal die Raw-Def.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: dennisk am 22 Februar 2021, 10:24:00
Hier mal die RAW Def:
defmod sd serviced fhem
attr sd serviceSudo 0

setstate sd running
setstate sd 2021-02-21 18:02:47 error none
setstate sd 2021-02-21 18:02:47 state running
setstate sd 2021-02-21 18:02:47 status Active: active (running) since Sun 2021-02-21 18:01:56 CET;; 50s ago


An der Definition von Serviced habe ich seit Monaten nichts geändert. Das Ganze tritt bei mir reproduzierbar nur mit Deinen letzten beiden Commits auf, also bis 1.2.6 ist alles gut.
Ich hab inzwischen rausgefunden, dass mit Deinen letzten Änderungen die Variable $sudo auch dann den String 'sudo' enthält, obwohl serviceSudo auf 0 gesetzt ist. Im zweiten Teil wird ja noch der Inhalt von $login geprüft, und in Bezug auf diese Variable hast Du ja Änderungen vorgenommen (die mittlere Zeile ist neu):

my $login = AttrVal($name,"serviceLogin","");
$login .= $login ? " -p ".AttrNum($name,"servicePort",22) : "";
my $sudo = AttrNum($name,"serviceSudo",1) && $login !~ /^root@/ ? "sudo " : "";


Hilft Dir das schon weiter? Wenn Du noch mehr Infos brauchst, sag Bescheid.

Vielen Dank!
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 22 Februar 2021, 12:22:13
Mon dennisk,

tut mir leid, irgendwie verstehe ich Dein Problem noch nicht.
"serviceSudo" hatte schon immer den Default-Wert 1.
Wenn "serviceSudo 1" (Standard) gesetzt ist und "serviceLogin" nicht mit "root" beginnt, wird "sudo" verwendet, sonst nicht, daran hat sich auch nichts geändert.
Laut Deiner Raw Def sieht doch alles gut aus!? "error none" und "state running". Wo ist das Problem?

Ich habe bei mir zusätzlich gerade Deine Def angelegt mit : "define sd serviced fhem".
Dann habe ich "verbos 5" gesetzt und man sieht im Log/Event-Monitor sehr schön wie das "shell command" aussieht was dann ausgeführt wird.
Hier direkt nach dem Definieren:
2021.02.22 11:02:21 5:  sd: serviced_Set executing shell command: sudo systemctl status fhem
2021-02-22 11:02:21 serviced sd state: status
2021.02.22 11:02:21 4:  sd: Service "fhem" is started
2021-02-22 11:02:21 serviced sd state: running


Und hier mit gesetztem "serviceSudo 0":
2021.02.22 11:03:09 5:  sd: serviced_Set executing shell command: systemctl status fhem
2021-02-22 11:03:09 serviced sd state: status
2021.02.22 11:03:09 4:  sd: Service "fhem" is started
2021-02-22 11:03:09 serviced sd state: running


Man sieht dass direkt nach dem Definieren noch "sudo" verwendet wird und nach Setzen von "serviceSudo 0" nicht mehr.
Ich habe auch noch einmal durch den Code geschaut und kann in den letzten beiden Commits keine Änderung der sudo-Zeile feststellen, lediglich in der Zeile davor habe ich die $login-Variable angepasst und um "servicePort" erweitert.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: dennisk am 22 Februar 2021, 14:08:22
Ich habs jetzt nochmal nachvollzogen. Wenn ich die aktuellste Version 98_serviced.pm aus dem SVN nehme, dann erhalte ich nach dem Restart folgendes im Log:
2021.02.22 13:53:57 1: PERL WARNING: Can't exec "sudo": Datei oder Verzeichnis nicht gefunden at /usr/share/fhem/FHEM/98_serviced.pm line 266, <$fh> line 322.
2021.02.22 13:53:57 1: PERL WARNING: Can't exec "sudo": Datei oder Verzeichnis nicht gefunden at /usr/share/fhem/FHEM/98_serviced.pm line 270, <$fh> line 322.
2021.02.22 13:53:57 1: PERL WARNING: Use of uninitialized value $ret in concatenation (.) or string at /usr/share/fhem/FHEM/98_serviced.pm line 326.
2021.02.22 13:53:57 3: eval: {serviced_ExecFinished('sd|1|')}
2021.02.22 13:53:57 3: sd: Error:


Diese Fehler sind vorher nicht aufgetreten und treten auch nicht auf, wenn ich 98_serviced.pm auf den Stand vor den beiden letzten Commits (@20536) zurücksetze.
Also muss es zumindest irgendwas mit diesen Änderungen zu tun haben. Hast Du eine Idee?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 22 Februar 2021, 15:02:02
Ich habe nach wie vor keine Idee.

Nochmal langsam:
Du möchtest den Service "fhem" auf dem lokalen System überwachen!
Das soll ohne "sudo" passieren, richtig?

Kannst Du bitte bei dem entsprechenden FHEM Device "verbose 5" einstellen und im Event-Monitor mal den Filter auf den Namen von dem Device setzen. Dann mal bitte einen "get status" absetzen ohne gesetztes Attribut "serviceSudo" und einmal mit (auf 0) gesetztem Attribut. Die Ausgabe im Event-Monitor dann bitte hier posten.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: dennisk am 22 Februar 2021, 16:08:38
Ja genau, fhem.service wird unter dem Benutzer fhem gestartet. Über eine Polkit-Regel erteile ich dem Benutzer fhem die Berechtigung, den Systemd-Service fhem.service zu managen:
polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units") {
        if (action.lookup("unit") == "fhem.service") {
            var verb = action.lookup("verb");
            if (verb == "start" || verb == "stop" || verb == "restart") {
                if (subject.user == "fhem") {
                    return polkit.Result.YES;
                }
            }
        }
    }
});


Beim Versuch, das Ganze jetzt nochmal nachzustellen, habe ich gesehen, dass jetzt kein Fehler mehr auftritt  ???
Jetzt bin ich verwirrt. Vielleicht beobachte ich das einfach mal und melde mich dann nochmal, falls es wieder auftritt?
Tut mir leid, wenn ich jetzt für zusätzliche Arbeit gesorgt habe.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 25 Februar 2021, 11:28:48
Zitat von: dennisk am 22 Februar 2021, 16:08:38
Ja genau, fhem.service wird unter dem Benutzer fhem gestartet. Über eine Polkit-Regel erteile ich dem Benutzer fhem die Berechtigung, den Systemd-Service fhem.service zu managen:
polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units") {
        if (action.lookup("unit") == "fhem.service") {
            var verb = action.lookup("verb");
            if (verb == "start" || verb == "stop" || verb == "restart") {
                if (subject.user == "fhem") {
                    return polkit.Result.YES;
                }
            }
        }
    }
});


Beim Versuch, das Ganze jetzt nochmal nachzustellen, habe ich gesehen, dass jetzt kein Fehler mehr auftritt  ???
Jetzt bin ich verwirrt. Vielleicht beobachte ich das einfach mal und melde mich dann nochmal, falls es wieder auftritt?
Tut mir leid, wenn ich jetzt für zusätzliche Arbeit gesorgt habe.

Funktioniert es nun wie gewünscht?
Wenn ja, könntest Du bitte kurz erläutern was die Lösung war?

Danke.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: dennisk am 26 Februar 2021, 20:02:10
Ich muss leider sagen, ich habe nichts geändert und auf einmal hat es wieder ohne Fehlermeldung funktioniert. Ich kann wirklich nicht sagen, was das Problem war. Und ja, es funktioniert "wieder" wie gewünscht. Sorry nochmal für den Aufruhr...und vielen Dank für die schnelle Reaktion!
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 02 März 2021, 12:02:16
Hallo,

erstmal vielen Dank für das Modul  :) !

Seit Anfang Januar verwende ich es, um auf einem weiteren Raspi den tvheadend-Service zu überwachen. Funktioniert soweit auch prima. Nun habe ich - ich meine seit meinem letzten FHEM-Update am 28.Februar - plötzlich das Problem, dass immer, wenn FHEM startet (z.B. nach einem Update, aber auch nach einem Reboot), folgender Fehler im Log erscheint und der Status des Service auf error geht.


2021.03.02 11:23:58 3: tvheadend_service: Error: Wir gehen davon aus, dass der lokale Systemadministrator Ihnen die Regeln erklärt hat. Normalerweise läuft es auf drei Regeln hinaus: #1) Respektieren Sie die Privatsphäre anderer. #2) Denken Sie nach, bevor Sie tippen. #3) Mit großer Macht kommt große Verantwortung. sudo: Kein TTY vorhanden und kein »askpass«-Programm angegeben


Wenn ich den Status des Services neu abfrage (get status oder automatisch nach 5 Minuten) passt wieder alles. Vor dem Update letzten Sonntag hatte ich das Problem noch nicht (muss natürlich nicht zwangsläufig heißen, dass das Problem an der neuen Version von serviced liegt  ;) )

Irgendeine Idee?

Viele Grüße
Dieter
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Wernieman am 02 März 2021, 13:19:36
Hast Du die sudoers config des Ziels angepasst? Dann ist sie eventuell beim Update etwas kaput gegangen.

sudo: Kein TTY vorhanden und kein »askpass«-Programm angegeben
Hier möchte sudo ein Passwort, kann es aber nicht abfragen.

Eigentlich darf es anschließend nicht funktionieren .... liegt also nicht an FHEM sondern an der Config des Systemes (besonders sudo)
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 02 März 2021, 15:32:51
Ich bin bzgl. Linux ein ziemlicher Rookie. Auch wenn ich mich durch FHEM über viele Jahre damit ein wenig beschäftige, bleibt mein Wissen immer etwas oberflächlich  :-[

Der User mit dem ich auf dem Ziel-Raspi den tvheadend-Service überwache ist "pi". In der sudoers auf diesem Raspi steht u.a. "pi ALL=(ALL) NOPASSWD: ALL".

Was mich eben nach wie vor stutzig macht sind die Tatsachen, dass es
1. zwischen der Einrichtung meiner Überwachung im Januar und dem FHEM-Update am Sonntag, trotz einiger FHEM-Neustarts diese Meldung nicht gab und
2. reproduzierbar nach einer erneuten Statusabfrage die Abfragen wieder problemlos funktionieren (bis zum nächsten Start von FHEM)
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Otto123 am 02 März 2021, 16:33:52
ZitatAbfragen
Du meinst Status? status erfordert kein sudo
Laut gedacht: Oder wird jetzt aus irgendwelchen Gründen lokal versucht mit sudo ssh zu machen? Das kann aber nur Dan erklären. Er hat ja ev. was verändert.

@RockFan Wenn Du mal in ins restoredir schaust: https://wiki.fhem.de/wiki/Update#R.C3.BCcksichern_beim_Update_.C3.BCberschriebener_Dateien
Und einfach die alte 98_serviced.pm wieder zurückholst?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 02 März 2021, 18:04:09
Genialer wie ebenso einfacher Tipp  :)

Der Restore über die FHEM Oberfläche hat zwar nicht geklappt (die Funktion kannte ich noch gar nicht im Detail), da die einzelnen PM-Module gar nicht gefunden wurden. Aber auf Dateiebene habe ich dann die einzelnen Dateien gefunden und habe die Vorgängerversion des Moduls zurückkopiert.
Und siehe da: Nach "shutdown restart" ist wieder alles in Ordnung. Keine Meldung mehr und der Status des Service entspricht dem tatsächlichem Status ("running").

Nun denke ich, dass sich doch irgend etwas in der letzten Version eingeschlichen hat  ::)

Natürlich bräuchte man für die Statusabfrage kein sudo. Aber mit dem Modul kann ich eben auch den Service neu starten, wenn er nicht läuft. Das Modul wird sicherlich nicht unterscheiden, wann es sudo bräuchte und wann nicht (nehme ich mal an).


Viele Grüße
Dieter
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 02 März 2021, 18:19:42
Zitat von: Otto123 am 02 März 2021, 16:33:52
Du meinst Status? status erfordert kein sudo
Laut gedacht: Oder wird jetzt aus irgendwelchen Gründen lokal versucht mit sudo ssh zu machen? Das kann aber nur Dan erklären. Er hat ja ev. was verändert.

@RockFan Wenn Du mal in ins restoredir schaust: https://wiki.fhem.de/wiki/Update#R.C3.BCcksichern_beim_Update_.C3.BCberschriebener_Dateien
Und einfach die alte 98_serviced.pm wieder zurückholst?

Ich hatte im letzten Update einen kleinen Fehler korrigiert, der dafür gesorgt hat dass der Status beim ersten Definieren nicht abgerufen wurde.
Evtl. macht das bei Dir dann beim Start von FHEM Probleme.

Es wäre nett wenn Du das mit der angehängten Version noch einmal testen könntest.
Danke.

Gruß
Dan

EDIT: Test Modul entfernt!
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 02 März 2021, 19:10:13
Danke Dan!

Prima! Mit der Testversion von Dir funktioniert es.

Viele Grüße
Dieter
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 02 März 2021, 19:39:15
Zitat von: RockFan am 02 März 2021, 19:10:13
Danke Dan!

Prima! Mit der Testversion von Dir funktioniert es.

Viele Grüße
Dieter

Danke für's Testen Dieter!
Ich habe den Fix soeben mit v1.2.7 im SVN eingecheckt.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 03 März 2021, 09:07:54
Guten Morgen Dan,

leider unterscheiden sich die Testversion 1.2.7 von gestern Abend und die 1.2.7 in SVN, die ich gerade über update erhalten habe (ich habe die Dateien verglichen). Mein Problem ist somit wieder da.
Kannst Du das bitte nochmal prüfen.

Viele Grüße
Dieter
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 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.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag 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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 03 März 2021, 18:14:55
Yep, jetzt geht es wieder  :)

Viele Grüße
Dieter
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 04 März 2021, 10:30:52
Danke Dan!

Jetzt funktioniert auch die eingecheckte Version :)

Viele Grüße
Dieter
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 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:

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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 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.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag 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​
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 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:

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

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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 06 Mai 2021, 22:03:23
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:
$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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 06 Mai 2021, 23:13:41
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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 07 Mai 2021, 00:11:21
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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: RockFan am 07 Mai 2021, 23:24:47
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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: taskkill am 15 Januar 2022, 11:16:58
Guten Tag, ist es auch irgendwie möglich alle Dienste vom Rpi automatisch erfassen zu lassen und nur den Status anzuzeigen ?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: DeeSPe am 15 Januar 2022, 16:01:56
Zitat von: taskkill am 15 Januar 2022, 11:16:58
Guten Tag, ist es auch irgendwie möglich alle Dienste vom Rpi automatisch erfassen zu lassen und nur den Status anzuzeigen ?

Nein.

Gruß
Dan
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: JensS am 22 Januar 2022, 10:21:08
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: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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Wernieman am 22 Januar 2022, 14:14:24
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.Ä.)
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 29 April 2022, 13:08:04
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):

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:

# 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:

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:

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

Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Wernieman am 29 April 2022, 16:27:11
1, Arbeite besser mit /etc/sudoers.d/<toller Dateiname>  und lass die Original sudoers in Ruhe
2. Wie bearbeitest Du die sudoers?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 29 April 2022, 17:40:21
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.

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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Wernieman am 29 April 2022, 17:50:03
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.....
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 30 April 2022, 13:03:33
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:

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
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Wernieman am 30 April 2022, 14:03:38
Wenn Du schon sudo willst, warum rufst Du systemctl dann ohne sudo auf?

Richtig also:
sudo /usr/bin/systemctl restart dnsmasq
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 01 Mai 2022, 12:10:09
Sorry, habe ich dann auch gemerkt:

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:

[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


Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Wernieman am 01 Mai 2022, 17:45:46
Du kannst Rechte über sodu und/oder polkit vergeben. Steige mitlerweile bei Dir nicht mehr durch. Wo ist jetzt der sudo-Befehl eingetragen, auf welcher Maschiene und von wo rufst Du es auf?
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 02 Mai 2022, 13:43:41
Hallo,

also ich verwende von  fhem aus serviced für zwei Maschinen:
a) lokal für den dnsmasq - service (da treten die Probleme nach dem Update auf bullseye auf:

2022.05.02 13:21:02 3: dnsmasq: 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

Wenn ich den status oder einen restart von diesem Dienst über das serviced - Ojekt abfragen / machen
möchte.
Auf dieser Maschine läuft polkit,  offensichtlich mit dem Update auf bullseye.

b) Remote über serviced und ssh.
Hier läuft polkit nicht und alles funktioniert wie bisher.

Gibt man in die fhem - Zeile folgendes ein

{qx(sudo /usr/bin/systemctl status dnsmasq)}
{qx(sudo /usr/bin/systemctl restart dnsmasq)}
{qx(sudo /bin/systemctl status dnsmasq)}
{qx(sudo /bin/systemctl restart dnsmasq)}

Wird mir 2 x mal der status von dnsmasq und 2 x mal ein restart durchgeführt.
Über das serviced - Modul geht es nicht mehr und die obige Fehlermeldung, mit der Auffforderung das Passwort interaktiv über ein Terminal  wird ausgegeben.

Da alles über eine ssh-Shell oder über die Kommandozeile von fhem (s.o.) funktioniert, kann es an dem Eintrag in der sudoers - Datei nicht liegen.

Es muss also an polkit liegen, dass ist das einzige, was offensichtlich seit dem update auf bullseye neu ist.
(siehe auch den Post oben mit den beiden Links zu den Aufgaben des policy kits, mit dem wohl das serviced - Modul irgendwie nicht mehr zurecht kommt)

ich habe in meinem fhem die Anweisung:

DoSet("dnsmasq","restart"); # serviced - Ojekt dnsmasq

durch


qx(sudo /bin/systemctl restart dnsmasq);

ersetzt und jetzt funktioniert der code - Teil wieder.

whereis dnsmasq zeigt /user/bin an
Aber dnsmasq ist sowohl unter /bin, als auch unter /usr/bin vorhanden.

Elektrolurch
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Wernieman am 02 Mai 2022, 14:57:36
Dann würde ich eher auf ein Problem im Modul Tippen.
Titel: Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
Beitrag von: Elektrolurch am 03 Mai 2022, 11:15:38
Ja, sehe ich auch so:

  if ($hash->{LOCKFILE})
  {
    $hash->{helper}{RUNNING_PID} = BlockingCall("serviced_ExecCmd","$name|$cmd|$com|$line","serviced_ExecFinished");
  }
  else
  {
    $hash->{helper}{RUNNING_PID} = BlockingCall("serviced_ExecCmd","$name|$cmd|$com|$line","serviced_ExecFinished",301,"serviced_ExecAborted",$hash);
  }


Für das polkit ist dieser Aufruf mit sudo quasi "ohne Mensch am Terminal" und wird deshalb blockiert.
Ein Aufruf mit qx(sudo /bin/systemctl restart dnsmasq) aus fhem heraus funktioniert dagegen.
Ich verstehe die Logik im Modul sowieso nicht: Hier wird ja wohl blocking aufgerufen, warum dann auch noch den Aufwand mit einem callback? Dann hätte man das ja auch non-blocking machen können.
Oder wenn blocking, dann gleich mit einem System-Call wie oben.

Elektrolurch