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
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. ;)

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
Da hat sich jemand an meinen Wunsch erinnert :) https://forum.fhem.de/index.php/topic,40127.0.html?PHPSESSID=i448rubf72kfv6fhovik4n52h5

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
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:
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
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-Raspberrysverschieben 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
/etc/init.d und /etc/systemd/system/ sind Verzeichnisse.

Aus dem ersten Post:

Die Pfade ermitteln mit:
which systemctlOder (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
* 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
* 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
* 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.

* 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. ;)

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
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 statusWar 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
Was hat denn in diesem Fehlerfall die Status Ausgabe aus der Konsole gezeigt?
sudo service alexa statusWar 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
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
Setz mal am serviced Gerät:
attr <name> serviceRegexFailed dead|failed|exited
Bin unsicher ob ich das als Default übernehmen sollte. ???

Gruß
Dan

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
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
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
   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.

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
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
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
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
* 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.

* 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. ::)

* 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
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
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
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 agoaus.

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

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
Zitat
RPI 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)

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
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 apache2wenn 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
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
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
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
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
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
my $sudo = AttrNum($name,"serviceSudo",1) && $login !~ /^root@/ ? "sudo " : "";

Danke.
Ist so eingecheckt!

Gruß
Dan