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

Begonnen von DeeSPe, 22 November 2017, 01:03:15

Vorheriges Thema - Nächstes Thema

DeeSPe

Zitat von: synaps-o-dan am 25 November 2017, 19:06:22
Coole Idee, werde ich ausprobieren. Eine Frage vorab: aktuell ist bei mir der user fhem kein sudoer, sondern hat nur relativ eingeschränkt Rechte. Spricht aus Sicherheitsgründen irgendetwas dagegen, dem user fhem Zugriff auf systemd zu erlauben? Wenn fhem von außen (trotz bestmöglicher Absicherung) gekapert wird?
Liebe Grüße,
Daniel

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

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

DS_Starter

#46
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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DeeSPe

Zitat von: DS_Starter am 27 November 2017, 08:36:01
* Startverzögerung von 2 Minuten oder höher (10) geht nicht mehr -> 3 Stellen in autoStart zulassen

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

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

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

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

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

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

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

DeeSPe

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
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

DeeSPe

Zitat von: synaps-o-dan am 25 November 2017, 19:06:22
Coole Idee, werde ich ausprobieren. Eine Frage vorab: aktuell ist bei mir der user fhem kein sudoer, sondern hat nur relativ eingeschränkt Rechte. Spricht aus Sicherheitsgründen irgendetwas dagegen, dem user fhem Zugriff auf systemd zu erlauben? Wenn fhem von außen (trotz bestmöglicher Absicherung) gekapert wird?
Liebe Grüße,
Daniel

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

Weitere Dienst zum Erlauben kommagetrennt anhängen.

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

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

raiderxxl

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

DeeSPe

Zitat von: raiderxxl am 01 Dezember 2017, 15:25:01
homebridge: state failed      status Active: active (exited) since Fr 2017-12-01 15:08:04 CET; 1min 37s ago

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

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

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

Sobald ein RegEx matcht wird dieser als state übernommen.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

MadMax-FHEM

#52
Zitat von: DeeSPe am 01 Dezember 2017, 21:34:13
Alle RegEx können über die Attribute serviceRegex... selbst angepasst werden.
Die RegEx werden in folgender Reihenfolge abgearbeitet:
serviceRegexStarting
serviceRegexStopped
serviceRegexFailed
serviceRegexStarted

Sobald ein RegEx matcht wird dieser als state übernommen.

Gruß
Dan

Hi Dan,

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

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

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


serviceRegexFailed failed
serviceRegexStarted active
serviceRegexStopped inactive|dead


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

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

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

sudo service alexa status

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

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

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

Hat lange gedauert das so rauszufinden...

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

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

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

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

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

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

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

Gruß, Joachim

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

und bei Fehler (festgestellt vom Scriot beim Start innerhalb der ersten 5s und exit code 7):
Active: failed (Result: exit-code) since Mon 2017-12-18 14:46:35 CET; 4s ago
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

DeeSPe

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
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

no_Legend

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.

DeeSPe

Zitat von: DeeSPe am 01 Dezember 2017, 21:34:13
Alle RegEx können über die Attribute serviceRegex... selbst angepasst werden.
Die RegEx werden in folgender Reihenfolge abgearbeitet:
serviceRegexStarting
serviceRegexStopped
serviceRegexFailed
serviceRegexStarted

Sobald ein RegEx matcht wird dieser als state übernommen.

Entweder selbst die RegEx(s) anpassen und/oder wenn Dein System systemd unterstützt entsprechend homebridge gleich als systemd statt initd einrichten.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

no_Legend

Zitat von: DeeSPe am 16 Januar 2018, 19:55:33
Entweder selbst die RegEx(s) anpassen und/oder wenn Dein System systemd unterstützt entsprechend homebridge gleich als systemd 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.

no_Legend

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.

DeeSPe

MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

no_Legend

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.