[HowTo] fhem als service unter systemd starten

Begonnen von betateilchen, 05 Juni 2016, 13:30:26

Vorheriges Thema - Nächstes Thema

betateilchen

Dieser Thread ist nicht für Linux-Anfänger gedacht!

Voraussetzungen:

  • Alle Befehle auf der Systemconsole müssen mit root-Rechten ausgeführt werden
  • Die Anleitung geht von einem Debian-basierten System aus
  • fhem sollte bereits installiert sein und korrekt funktionieren
  • während der Umstellung darf fhem selbst nicht laufen




1. Benötigte Pakete installieren, falls nicht schon vorhanden


apt-get -y install systemd systemd-sysv



2. Altes Startskript deaktivieren


update-rc.d fhem remove



3. unit-file /etc/systemd/system/fhem.service mit folgendem Inhalt erstellen


[Unit]
Description=FHEM Home Automation

[Service]
Type=forking
#ExecStartPre=/opt/hmusbcfg/hmland -d -p 1234 -r 0
ExecStart=/etc/init.d/fhem start
ExecStop=//etc/init.d/fhem stop
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target




4. Den systemd über Änderungen seiner Konfiguration informieren


systemctl --system daemon-reload



5. Den Service fhem zuerst manuell starten, um zu sehen, ob alles funktioniert


systemctl start fhem.service



systemctl status fhem.service


sollte als Ausgabe liefern:


fhem.service - FHEM Home Automation
  Loaded: loaded (/etc/systemd/system/fhem.service; enabled)
  Active: active (running) since Sun, 05 Jun 2016 12:53:12 +0200; 4min 6s ago
Main PID: 5007 (perl)
  CGroup: name=systemd:/system/fhem.service
  └ 5007 perl fhem.pl configDB

Jun 05 12:53:10 cubie.betateilchen.de fhem[5005]: Starting fhem...



6. Den Service beim Booten automatisch starten


systemctl enable fhem.service



7. Das System einmal per reboot neu starten, fhem sollte danach automatisch wieder laufen.




Achtung:

Nach dieser Änderung reagiert ein shutdown innerhalb von fhem nicht mehr wie gewohnt.

Da im unit-file ein Restart= definiert wurde, wird nach einem shutdown der fhem Prozess nach 5 Sekunden automatisch wieder neu gestartet. Wer das nicht möchte, kommentiert die Restart= Zeile im unit-file einfach aus.

Ebenfalls im unit-file ist die auskommentierte Zeile zum Starten eines hmland enthalten, falls dieser benötigt wird. Das ist im Moment eine Krücke, ich werde für hmland auch noch ein unit-file erstellen. Aber zum Testen war das so ganz ok.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Newbie

Hallo Betateilchen,

hab mich mal versucht und komme irgendwie nicht ans Ziel.

systemctl status fhem.service - ergibt folgendes:

● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: ena
   Active: active (running) since Tue 2016-06-28 19:47:38 CEST; 29s ago
  Process: 651 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
  Process: 542 ExecStartPre=/opt/hmcfgusb/hmland -d -p 1234 -r 0 (code=exited, s
   CGroup: /system.slice/fhem.service
           └─719 /opt/hmcfgusb/hmland -d -p 1234 -r 0

Jun 28 19:47:36 odroid systemd[1]: Starting FHEM Home Automation...
Jun 28 19:47:36 odroid hmland[542]: Daemon with PID 558 started!
Jun 28 19:47:37 odroid fhem[651]: Starting fhem...
Jun 28 19:47:37 odroid fhem[651]: Daemon with PID 719 started!
Jun 28 19:47:38 odroid systemd[1]: Started FHEM Home Automation.


Ergebnis FHEM mit Browser nicht erreichbar. Läuft doch aber oder???

Noch ne Frage zu Punkt 3 -

muss es nicht

Zitat#ExecStartPre=/opt/hmcfgusb/hmland -d -p 1234 -r 0

und

ZitatExecStop=/etc/init.d/fhem stop

heißen?

System ist ein Odroid XU4 mit Ubuntu 16.04

vg Jens
fhem-6.1 (configDB+DbLog)  auf ODROID-XU4

Wernieman

Ob er läuft, solltest Du nicht mit dem Browser, sondern bei Problemen direkt am Pi Testen (ssh):
(Alle Ausgaben sind nur als Beispiel zu sehen)

1. Läuft der Prozess?
ps aux | grep [f]hem
fhem      1601  0.3  1.3 186512 106840 ?       S    Jun23  29:26 /usr/bin/perl /opt/fhem/fhem.pl /opt/fhem/fhem.cfg
fhem     26600  0.0  1.2 186512 101648 ?       S    06:31   0:00 /usr/bin/perl /opt/fhem/fhem.pl /opt/fhem/fhem.cfg


Alternativ um Sicherzugehen, das nur eine Instanz läuft:
pstree | grep [f]hem
|-fhem.pl---fhem.pl


Ich habe 2x fhem, da eines "nonblocking" mpd bedient. Wenn untereinander Auftaucht, hast Du ein Problem

2. Wurde auf dem Port konnektet?
es sollten die FHEM Ports auftauchen, im Standard:
sudo netstat -lntp | grep perl
tcp        0      0 0.0.0.0:8083            0.0.0.0:*               LISTEN      1601/perl       
tcp        0      0 0.0.0.0:8084            0.0.0.0:*               LISTEN      1601/perl       
tcp        0      0 0.0.0.0:8085            0.0.0.0:*               LISTEN      1601/perl       
tcp        0      0 0.0.0.0:7072            0.0.0.0:*               LISTEN      1601/perl       


3. Ist FHEM erreichbar (wenn Telnet nicht abgeschaltet)
telnet localhost 7072
bzw. für die Eiligen, wenn kein Password vergeben wurde:
echo "list" | nc localhost 7072
..... FHEM-Configuration soll durchscrollen .....



4. Jetzt local Prüfen ob FHEM erreichbar ist
wget localhost:8083 -O
..... HTML-Code sichtbar, keine Fehlermeldungen .....


5. ab jetzt kommt erst Dein obiger Browser ins Spiel
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Newbie

Hallo Werniemann,

danke für die Tipp's, es gab wirklich mehrere FHEM-Proszesse.
Alles bereinigt und FHEM-Autostart funktioniert nun.
Gibt zwar noch ein kleines Problem beim HMCFGUSB unter systemd starten, aber ich weiss ja jetzt wo ich ansetzen kann.

Zitat● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2016-06-28 23:48:45 CEST; 16h ago
Main PID: 1071 (perl)
   CGroup: /system.slice/fhem.service
           └─1071 perl fhem.pl configDB

Jun 28 23:48:44 odroid systemd[1]: Starting FHEM Home Automation...
Jun 28 23:48:44 odroid hmland[987]: Daemon with PID 988 started!
Jun 28 23:48:44 odroid fhem[992]: Starting fhem...
Jun 28 23:48:45 odroid systemd[1]: Started FHEM Home Automation.

danke und schönen Tag noch, Jens
fhem-6.1 (configDB+DbLog)  auf ODROID-XU4

frank

danke für die anleitung.
ich musste heute auf systemd umstellen. wie es aussieht funktioniert es auch "eigentlich".

● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled)
   Active: inactive (dead) since Sat 2016-08-27 19:17:17 CEST; 5s ago
  Process: 2134 ExecStop=/etc/init.d/fhem stop (code=exited, status=0/SUCCESS)
  Process: 2015 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
Main PID: 2017 (code=exited, status=0/SUCCESS)

Aug 27 19:13:38 raspberrypi systemd[1]: Starting FHEM Home Automation...
Aug 27 19:13:38 raspberrypi fhem[2015]: Starting fhem...
Aug 27 19:13:38 raspberrypi systemd[1]: Started FHEM Home Automation.
Aug 27 19:17:16 raspberrypi systemd[1]: Stopping FHEM Home Automation...
Aug 27 19:17:16 raspberrypi fhem[2134]: Stopping fhem...
Aug 27 19:17:17 raspberrypi systemd[1]: Stopped FHEM Home Automation.


nach einem reboot oder fhem shutdown gibt es aber regelmässig ein "Failure" mit ExecStop.
● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled)
   Active: active (running) since Sat 2016-08-27 19:27:30 CEST; 1min 4s ago
  Process: 762 ExecStop=/etc/init.d/fhem stop (code=exited, status=1/FAILURE)
  Process: 857 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
Main PID: 860 (perl)
   CGroup: /system.slice/fhem.service
           └─860 perl fhem.pl fhem.cfg

Aug 27 19:27:29 raspberrypi fhem[857]: Starting fhem...
Aug 27 19:27:30 raspberrypi systemd[1]: Started FHEM Home Automation.


ein explicites "systemctl stop fhem.service" läuft hingegen sauber durch, wie oben zu sehen ist.
ich benutze das fhem.3-script mit der auskommentierung, wie in diesem thread https://forum.fhem.de/index.php/topic,53825.0.html, auf pi3.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

chris1284

auch wenn es nicht für linux anfäönger ist wäre es gut wenn du einen kleinen satz zum warum und wieso einbauen könntest.

Zitatfhem als service unter systemd starten
was hat das für einen hintergunden , warum macht das sinn?

decaflo

Zitat von: chris1284 am 27 August 2016, 22:14:40
was hat das für einen hintergunden , warum macht das sinn?

systemd wird nach und nach bei fast allen Linuxdistributionen eingesetzt. Je nach Distribution funktioniert dann der Start über Startscript unter /etc/init.d/ nicht mehr.
Du musst aber nichts umstellen, wenn Dein System reibungslos läuft. Anders sieht es u.U. bei künftigen Neuinstallationen aus.

Amenophis86

Habe das Ganze heute auch mal auf meiner zweiten FHEM Umgebung eingerichtet und getestet.

1.
Zitat von: Newbie am 28 Juni 2016, 20:07:50
muss es nicht

und
ZitatExecStop=/etc/init.d/fhem stop
heißen?

Ist richtig. Es darf nur ein / sein.

2. Ich musste meinen Pi nach Schritt 3 bzw 4 erst neustarten, damit ich mittels der Befehle testen konnte, ob FHEM läuft, oder nicht. Vorher kam immer ein Fehler. Grund konnte ich noch nicht ermitteln. Nach einem Restart hat es aber geklappt. Dann konnte ich auch die letzten Schritte ausführen, bzw. habe es testweise vorher schon mal zum Autostart hinzugefügt gehabt, obwohl es sich nicht manuell starten lassen wollte und es hat geklappt.

3. Was mich noch interessieren würde ist, ob es eine Option gibt, dass FHEM nicht gestartet wird, wenn es zB innerhalb einer bestimmten Zeit X mal neugestartet wurde, weil irgendein Fehler ständig einen neustart erzwingt? Hatte vorher Monit genutzt und da ging es ganz gut sowas einzustellen.

Sonst finde ich es ganz gut. Bin mir nur noch unsicher, ob ich das oder Monit besser finde. Bei Monit sehe ich aktuell noch mehr Möglichkeiten.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

mareb

Moin,

mir ist nicht ganz klar, warum trotz systemd das init-skript verwendet wird. Genau das will man ja eigentlich loswerden.

Bei mir sieht die Service-Section so aus:

[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
Restart=on-failure


Just my 2 cents,
Markus

Wernieman

Das ist so nicht gaaans richtig. Du kannst auch mit systemd Scipte starten, was auch per se nicht falsch ist. Ob man aber unbedingt die in inet.d nehmen muß ....

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Amenophis86

Denke das es eher darum geht, dass so ziemlich jeder diese Skripte auf Grund der Installation in der init.d hat und daher dieser Ort genommen wurde. Warum jetzt mit dem Skripten und nicht mit direktem Start gearbeitet wurde, würde ich mir damit erklären, dass manche mit der cfg und manche mit DB arbeiten. Wobei man dies natürlich auch hätte berücksichtigen können und einfach zwei Erklärungen gemacht hätte ;)

Egal wie, es geht beides und macht keinen Unterschied, wie man es gemacht hat. Ich zum Beispiel arbeite auch mit dem Script, liegt aber daran, dass ich mir noch eine Pushover Nachricht zukommen lasse, sobald FHEM beendet wurde, oder startet. Diese Nachricht soll nicht von FHEM kommen, weshalb ich sie über das Script ausführen lasse.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

mareb

nja, ist wohl Geschmackssache...
ich denke nur, dass die Zeit von init.d nun endlich ist - daher versuche ich meinen Kram auf systemd umzustellen. (was ich nach anfänglicher Skepsis mittlerweile echt gut finde).

BTW: Um Sachen nach oder vor einem ExecStart auszuführen:
ExecStartPre=, ExecStartPost=
Nach einem ExecStop:
ExecStopPost=

daywalkero

#12
Ich hab jetzt gemäß obigem Script fhem zum laufen gebracht. Füge ich hmcfgusb hinzu, passiert gar nichts, da startet auch fhem nicht. Bei Homebridge das selbe.
Kann mir jemand beim Anpassen helfen? Aktuell starte ich nach einem Reboot alles händisch.

hmcfgusb über die init.d von fhem starten klappt - aber Homebridge leider nicht.

Amenophis86

Die # rausgenommen in der hmcfgusb Zeile bei Schritt 3??
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

daywalkero

Klar. Tut sich gar nichts. Hmcfgusb wäre auch nebensächlich, wie gesagt, den habe ich über das Script vom Fhem in init.d mit gestartet. Das funktioniert blöder Weise nicht mit Homebridge.

Wernieman

Eigentlich ist doch Hmcfgusb ein eigener Deamon ... und man sollte dann systemd seine arbeit machen lassen es nacheinander zu starten.

also:
Eine eigene Config für Hmcfgusb und abhängigkeiten von fhem zu Hmcfgusb definieren

alternativ ... eigenes Start/Stop-Script definieren ..
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

daywalkero

Also so?

[Unit]
Description=HMCFGUSB

[Service]
Type=forking
ExecStart=/opt/hmcfgusb/hmland -d -p 1234 -r 0
Restart=always
RestartSec=5


Den Kram dann in eine hmcfgusb.service und entsprechend wie im ersten Beitrag einbinden? Also daemon-reload, danach Start und alles ist gut?

Wernieman

Naja .. DU hast Ihm nicht gesagt, das fhem es benötigt, z.B.:
[Install]
WantedBy=.....

Bzw. in der systemd-fhem-config, das er diesen "Dienst" braucht ....

p.s. auch ein "stop" währe nicht schlecht ;o)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

mahowi

"Stop" ist nicht zwingend notwendig, da ohne Angabe einfach ein kill an den Prozeß geschickt wird.
Zitat von: man systemd.serviceIf this option is not specified, the process is terminated by sending the signal specified in KillSignal= when service stop is requested.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Wernieman

Ich zitiere:
"währe nicht schlecht"

Ich verlasse mich nicht gerne auf automatismen ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

mareb

Du kannst mit
journalctl -xn -u <hier servicename, vermutlich "fhem">
schauen, was Dein Dienst da macht.

Für homebridge solltest Du ein eigenes systemd-Servicefile anlegen. Bei mir sieht das so aus:

# cat /etc/systemd/system/homebridge.service
[Unit]
Description=Node.js HomeKit Server
After=syslog.target network-online.target

[Service]
Type=simple
User=homebridge
EnvironmentFile=/etc/default/homebridge
ExecStart=/usr/bin/homebridge $HOMEBRIDGE_OPTS
Restart=on-failure
RestartSec=10
KillMode=process

[Install]
WantedBy=multi-user.target

daywalkero

#21
Habs geschafft :)

Alexa Autostart (aktuell sind noch Anpassungen an der Alexa-Config bezüglich der Keys notwendig):
[Unit]
Description=Alexa Fhem
Requires=fhem.service

[Service]
User=pi
Type=simple
WorkingDirectory=/opt/alexa-fhem
ExecStartPre=/bin/sleep 5
ExecStart=/opt/alexa-fhem/bin/alexa
#Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target


Homebridge (hier hat mir die Angabe des Benutzers gefehlt und deshalb ging es nicht):

[Unit]
Description=Homebridge
After=alexa.service

[Service]
User=pi
Type=simple
ExecStart=/usr/bin/homebridge

[Install]
WantedBy=multi-user.target


Autostart FHem (noch übers init.d Script. Wichtig war hier After=network.target da er sonst die Ports nicht öffnen konnte. HMCFGUSB läuft im init.d Script mit an)
[Unit]
Description=FHEM Home Automation
After=network.target

[Service]
Type=forking
ExecStart=/etc/init.d/fhem start
ExecStop=/etc/init.d/fhem stop
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target


Die Dateien sind noch nicht final, laufen aber erstmal sauber. Sieht man u. A. auch am #Restart bei Alexa - könnte man dann theoretisch ja ganz raus löschen. Tut aber auch so nicht weh.

mareb

Zitat von: daywalkero am 22 Dezember 2016, 16:23:30
Habs geschafft :)

Autostart FHem (noch übers init.d Script. Wichtig war hier After=network.target da er sonst die Ports nicht öffnen konnte. HMCFGUSB läuft im init.d Script mit an)

Ich würde für den HMCFGUSB-Adapter noch ein eigenes service-file anlegen.
Im FHEM-File kannst Du das dann in der UNIT-Section mit

[Unit]
...
Wants=...

referenzieren. Dann würde der USB-Adapater immer mitgestartet, wenn fhem gestartet wird.

Otto123

Hallo betateilchen,

als ziemlicher Linux Anfänger habe ich versucht den Umstieg von SysVinit nach Systemd zu verstehen.
Ist dieser Befehl (Im ersten Post) zum Entfernen des alten Dienstes nicht nur ein Teil?update-rc.d fhem remove
Es müsste doch vielmehr update-rc.d fhem disableheißen?
Oder muss man besser erst disable und dann remove machen?

Das Wiki Ubuntu sagt dazu
ZitatBei einer Aktualisierung (Update) des entsprechenden Pakets merkt die Paketverwaltung, dass diese Links nicht mehr existieren, und legt sie wieder an, da das System davon ausgeht, dass das Paket zum ersten Mal installiert wird.

Ich weiß im Falle FHEM wird eigentlich kein Update des Paketes durchgeführt, insofern ist mein Einwand vielleicht etwas philosophisch.  ;)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

AB1970

Danke an alle für eure Hilfe !
Hmcfgusb, alexa, homebridge und FHEM laufen bei mir nun unter systemd.

Das Service File für FHEM:

[Unit]
Description=FHEM Home Automation
After=hmcfgusb.service
Wants=hmland.service

[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target   




raimundl

Danke AB1970!

Könntest du auch die Systemd für die anderen Dienste veröffentlichen. Insbesondere Alexa.

LG
Homematic: Licht, Heizung, Alarm, Alexa ... auf einen RaspberryPi3+mit OS "Stretch" und RPI-RF-MOD mit piVCCU3 (HMCCU), ca. 40 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes....

AB1970

#26
Stellt bitte erst einmal sicher, dass sich systemd nicht die alten Init.d Startscripte schnappt
Hierzu habe hmcfgusb,fhem,Alexa und homebridge erstmal abgemeldet:

sudo systemctl disable <name>.service

Danach im Verzeichnis /etc/init.d die Startscripte von hmcfgusb,fhem,Alexa und homebridge in <name>.save umbenennen.

Anschliessend müssen die entsprechenden <name>.service Dateien in etc/systemd/system erstellt werden.

Damit es systemd auch mitbekommt, dass sich was geändert hat, noch ein:

sudo systemctl daemon-reload

Schlussendlich macht es Sinn alle Services mit

sudo systemctl start <name>.service

zu starten und mit z.b. htop zu schauen, ob sie wirklich laufen.

sudo systemctl status <name>.service
sudo journalctl -u <name>.service

hilft einen Überblick zu bekommen, wenn was schiefläuft.

zuletzt dafür sorgen, dass es beim Booten gestartet wird:

sudo systemctl enable <name>.service

Bitte oben den Hinweis beachten: Das ist nichts für Anfänger und macht bitte vorher eine Sicherung der Systems.

---HMcfgUsb

[Unit]
Description=HMCFGUSB

[Service]
Type=forking
ExecStart=/opt/hmcfgusb/hmland -d -p 1234 -r 0
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

-- FHEM
Gefunden im  https://wiki.fhem.de/wiki/Benutzer:Benheim/Startscript_systemd
aber mit der Änderung für hmcfgusb ( nur nötig  wenn man auch einen Homematic USB stick benutzt)


[Unit]
Description=FHEM Home Automation
After=hmcfgusb.service
Wants=hmland.service

[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

-- Alexa

[Unit]
Description=Alexa Fhem
Requires=fhem.service

[Service]
User=<user> (most probably "pi")
Type=simple
WorkingDirectory=/opt/fhem/alexa-fhem
ExecStartPre=/bin/sleep 5
ExecStart=/opt/fhem/alexa-fhem/bin/alexa
#Restart=always
RestartSec=5
StandardOutput=journal

[Install]
WantedBy=multi-user.target

--Homebridge

[Unit]
Description=Homebridge
After=alexa.service

[Service]
User=<user> (most probably "pi")
Type=simple
ExecStart=/usr/bin/homebridge

[Install]
WantedBy=multi-user.target




raimundl

Vorerst Danke!

Deine Ausführungen bringen mich im Thema systemd sicher weiter. Ich werde alles sorgfältig ausprobieren und dann auch berichten.
Homematic: Licht, Heizung, Alarm, Alexa ... auf einen RaspberryPi3+mit OS "Stretch" und RPI-RF-MOD mit piVCCU3 (HMCCU), ca. 40 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes....

Tsturm

An AB1970... hättest Du noch dein Homebridge script - du hast versehentlich zweimal das Alexa-Script geposted...
VG timmo

AB1970

Danke für den Hinweis, ich hab es geändert :-)

popy

Danke für den Thread.
Hatte bei booten meines RPI2 wenn init.d verwendet wurde immer sehr viel "Network not reachable" Einträge nach einem reboot.
Zutun natürlich mit den ganzen Modulen die auf Netzwerk zugreifen (HUE, KODI usw.).
Wie oben schon kurz beschrieben sollte die Abhängigkeit vom Netzwerk in die service file geschrieben werden:

Wants=network.target
After=network.target


Meine fhem.service file schaut jetzt so aus:


[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target

[Service]
Type=forking
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target


Funktioniert 1a und keine Fehler mehr nach einem Reboot.

PS.: Sollte ev. angedacht werden dass bei einer fhem installation mit apt-get dies automatischa uf systemd umgestellt wird wenn vorhanden?

pOpY

volschin

In vielen Bereichen ähnlich, sieht mein derzeitiges Unit-Script etwas anders aus:
[Unit]
Description=FHEM Home Automation
After=network.target
#Wants=hmland.service

[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
ExecStop=/usr/bin/perl fhem.pl 7072 "shutdown"
Restart=on-failure

[Install]
WantedBy=multi-user.target


Einfach das alte Init-Bash Script aufzurufen, mag zwar schnell gehen, verschenkt aber Potentiale von systemd.

Ich bin immer noch an dem Stop / Fehler-Teil dran und suche nach besseren Lösungen.
SIGSTOP wird ja leider in Perl nicht durchgereicht, deshalb bin ich wieder bei shutdown gelandet.
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

mahowi

Bei mir sieht das so aus:
[Unit]
Description=FHEM Home Automation
Documentation=http://fhem.de/commandref.html
After=network.target

[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
PIDFile=/var/run/fhem/fhem.pid
ExecStart=/usr/bin/perl fhem.pl configDB
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target


In global habe ich das Attribut pidfilename auf /var/run/fhem/fhem.pid gesetzt. Damit wird FHEM über die PID gestoppt.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

volschin

Warum arbeitest Du mit pidfile? In meinem Verständnis ist dieses Vorgehen veraltet und wird durch die Control Groups von systemd auf Kernelebene übernommen. Mir ist bisher keine pid innerhalb der cgroup abhanden gekommen.

Ich habe nochmal im Code von fhem.pl geschaut und auf den ersten Blick wird SIGTERM dort sauber mit der Shutdown-Prozedur behandelt. Damit könnte man ExecStop tatsächlich entfallen lassen.

Aus welchem Grund benutzt Du
RestartSec=5
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

mahowi

Das mit dem PIDfile-Eintrag habe ich der Manpage zu systemd.service entnommen:
ZitatIf set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can identify the main process of the daemon. systemd will proceed with starting follow-up units as soon as the parent process exits.

RestartSec=5 habe ich vermutlich von irgendwoher übernommen. Das dürfte überflüssig sein.

Zumindest funktionieren start, stop und restart problemlos.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

volschin

#35
Zitat von: https://lists.freedesktop.org/archives/systemd-devel/2013-February/009201.htmlMAINPID is determined by systemd.

- For Type=simple/dbus/notify, it's usually the first process started.

- For Type=forking, systemd can guess based on the cgroup's contents –
each service runs in a separate cgroup (for example, run
"systemd-cgls") and systemd can use this information to find the right
process.

- But if PIDFile is specified, then systemd doesn't try to guess but
just uses the pidfile written by mysqld itself.

Der Vorteil aus meiner Sicht, alles in der cgroup wird bei Bedarf gekillt und das ist mehr als der Hauptprozess (siehe unten)
pi@ha ~ $ sudo systemctl -l status fhem
● fhem.service - FHEM Home Automation
   Loaded: loaded (/lib/systemd/system/fhem.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2017-10-30 19:23:05 CET; 56min ago
     Docs: https://fhem.de/commandref.html
  Process: 539 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)
Main PID: 762 (perl)
   CGroup: /system.slice/fhem.service
           ├─  762 /usr/bin/perl fhem.pl fhem.cfg
           ├─23448 /usr/bin/perl fhem.pl fhem.cfg
           └─23461 hcitool name c0:ce:xx:xx:32:xx

Okt 30 19:23:03 ha systemd[1]: Starting FHEM Home Automation...
Okt 30 19:23:05 ha systemd[1]: Started FHEM Home Automation.
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

mahowi

Ich muß zugeben, daß ich mich nicht wirklich mit systemd auskenne. Ein Großteil meiner Linux-Kenntnisse stammt von vor über 15 Jahren.  8)

Zumindest ist laut Manpage die Erkennung der PID nicht immer zuverlässig bei forking:
Zitat von: https://www.freedesktop.org/software/systemd/man/systemd.service.htmlThe guessing algorithm might come to incorrect conclusions if a daemon consists of more than one process. If the main PID cannot be determined, failure detection and automatic restarting of a service will not work reliably.
[...]
In case more than one process remains, systemd will be unable to determine the main process, so it will not assume there is one. In that case, $MAINPID will not expand to anything. However, if the process decides to write a traditional PID file, systemd will be able to read the main PID from there. Please set PIDFile= accordingly.

Bringt es denn Nachteile mit sich, wenn man PIDfile verwendet?
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

devil77

Hallo, versuche mich auch gerade an Fhem als Service und soweit läuft alles.
Wenn ich aber in fhem eine shutdown+restart möchte dann wird fhem nur gestopt.
Es erfolgt kein automatischer Start von fhem und ich muß das ganze manuell starten.
Muss man dafür noch etwas extra einstellen?
Anbei meine service Files.

fhem.service
[Unit]
Description=FHEM service
Wants=hmcfgusb.service
After=network.target

[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl configDB
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target


hmcfgusb.service
Unit]
Description=HMCFGUSB

[Service]
Type=forking
ExecStart=/opt/hmcfgusb/hmland -d -p 1234 -r 0
Restart=on-failure

[Install]
WantedBy=multi-user.target

volschin

Kann ich bei mir nicht nachvollziehen.
Nov 01 13:27:00 ha systemd[1]: Starting FHEM Home Automation...
Nov 01 13:27:01 ha systemd[1]: Started FHEM Home Automation.
Nov 01 13:30:48 ha systemd[1]: fhem.service: Control process exited, code=exited status=3
Nov 01 13:30:48 ha systemd[1]: fhem.service: Unit entered failed state.
Nov 01 13:30:48 ha systemd[1]: fhem.service: Failed with result 'exit-code'.
Nov 01 13:30:53 ha systemd[1]: fhem.service: Service hold-off time over, scheduling restart.
Nov 01 13:30:53 ha systemd[1]: Stopped FHEM Home Automation.
Nov 01 13:30:53 ha systemd[1]: Starting FHEM Home Automation...
Nov 01 13:30:54 ha systemd[1]: Started FHEM Home Automation.


Um 13:30 Uhr habe ich ein "shutdown restart" ausgelöst.
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

betateilchen

Bevor hier ein Thread, in dem am Anfang eine funktionierende Anleitung steht, weiter durch Basteleien unbrauchbar wird, mache ich diesen Thread zu. Wer über systemd weiter diskutieren möchte, möge bitte einen eigenen Thread eröffnen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!