Autor Thema: Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern  (Gelesen 17801 mal)

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4204
  • Wer anderen eine Bratwurst brät...
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #45 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
FHEM 5.9, Brix, VIVO mini, RPi3, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Online DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5970
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #46 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
« Letzte Änderung: 27 November 2017, 08:45:16 von DS_Starter »
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, SSChatBot, SSCal, DbLog/DbRep, Log2Syslog, SMAPortal, Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4204
  • Wer anderen eine Bratwurst brät...
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #47 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
FHEM 5.9, Brix, VIVO mini, RPi3, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4204
  • Wer anderen eine Bratwurst brät...
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #48 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
FHEM 5.9, Brix, VIVO mini, RPi3, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4204
  • Wer anderen eine Bratwurst brät...
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #49 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
FHEM 5.9, Brix, VIVO mini, RPi3, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Offline raiderxxl

  • Full Member
  • ***
  • Beiträge: 278
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #50 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
 
FHEM VM Ubuntu-Server auf Intel® NUC-Kit NUC6i5SYH ESXi 6.5
FHEM auf Raspberry2 OSMC Hyperion und TTS

Homematic,TradfriHub und Lampen,WIFILight,Fritzbox,FritzDECT,NanoCul433,IT Steckdosen,Diverse Nachbar-Sensoren,XiaomiZigbee,
ESP_Signalduino,ESPEasy,Amad,HarmonyHub,WLED,MQTT,Tasmota....

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4204
  • Wer anderen eine Bratwurst brät...
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #51 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
FHEM 5.9, Brix, VIVO mini, RPi3, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 8833
  • NIVEAu ist keine Creme...
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #52 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
« Letzte Änderung: 18 Dezember 2017, 14:47:53 von MadMax-FHEM »
FHEM PI3B+ Buster: HM-CFG-USB, 40x HM, ZWave-USB, 6x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, KODI, alexa-fhem, ...
FHEM PI2 Stretch: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, KODI, ha-bridge, ...
FHEM PI3 Buster (Test)
FHEM PI3 Stretch (Test)
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4204
  • Wer anderen eine Bratwurst brät...
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #53 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
FHEM 5.9, Brix, VIVO mini, RPi3, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Offline no_Legend

  • Hero Member
  • *****
  • Beiträge: 1287
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #54 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
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4204
  • Wer anderen eine Bratwurst brät...
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #55 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 statt initd einrichten.

Gruß
Dan
FHEM 5.9, Brix, VIVO mini, RPi3, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Offline no_Legend

  • Hero Member
  • *****
  • Beiträge: 1287
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #56 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 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
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

Offline no_Legend

  • Hero Member
  • *****
  • Beiträge: 1287
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #57 am: 20 Januar 2018, 08:13:20 »
Läuft bei mir sehr Stabil.
Ist ein commit in das offiziell Repo geplant?

Gruß Robert
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4204
  • Wer anderen eine Bratwurst brät...
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #58 am: 20 Januar 2018, 09:11:13 »
Ist ein commit in das offiziell Repo geplant?

Ja, wird es geben.

Gruß
Dan
FHEM 5.9, Brix, VIVO mini, RPi3, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline no_Legend

  • Hero Member
  • *****
  • Beiträge: 1287
Antw:Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern
« Antwort #59 am: 20 Januar 2018, 09:17:23 »
Danke für deine schnelle Antwort.
Und danke für deine Arbeit

Gruß Robert
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

 

decade-submarginal