Hi,
ich habe beides Debmatic(CCU3) und fhem auf einem Intel Nuc unter Debian Buster laufen. Die Debmatic CCU3 braucht nach dem Neustart oder reboot meines iNUC sehr lange, bis alle Interfaces geladen sind. Das FHEM HMCCU modul benötigt aber beim Start eine laufende Debmatic CCU3, ansonsten werden die RPC Server Interfaces nicht gefunden, und der fhem HMCCU Server started nicht.
Wie kann ich den FHEM start verzögern, kann mir jemand auf die Sprünge helfen? ?
Ich habe schon verschiedene Lösungsmöglichkeiten gefunden, bin mir aber nicht sicher welches die richtige ist, und wo genau ich das einfügen muss:
1) Wants=xxx.service (Es gibt aber keine debmatic.service, nur ein Directory debmatic.service.wants, und eigentlich brauche ich ja ein fhem.service.wants ? );
2) ExecStartPre=/bin/sleep 120;
3) ExecStartPost=/bin/sleep 120;
4) ...
cat /etc/systemd/system/fhem.service
# $Id: fhem.service 16001 2018-01-26 11:54:41Z betateilchen $
[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target
[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always
[Install]
WantedBy=multi-user.target
Habe Debmatic noch nicht wirklich getestet. Aber du möchtest Fhem verzögern, daher sollte das so funktionieren.
nano /etc/systemd/system/fhem.service
Und das eintragen, was du unter Punkt 2 geschrieben hast.
# $Id: fhem.service 19235 2019-04-21 13:26:17Z betateilchen $
[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target
#Requires=postgresql.service
#After=postgresql.service
#Requires=mysql.service
#After=mysql.service
[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always
ExecStartPre=/bin/sleep 120
[Install]
WantedBy=multi-user.target
Danke, habs so wie von Dir vorgeschlagen eingebaut, und ich werde beim nächsten Reboot berichten.
Ich bin für eine Rückmeldung sehr interessiert.
Das gleiche Problem habe ich auch mit FHEM und Debmatic (funktioniert übrigens problemlos auf meinem RPI3, bis auf diese Geschichte), die Ursache hatte ich auch genauso indentifiziert, aber ich habe noch nicht die Zeit gefunden, um mich um diese Korrektur zu kümmern.
Vielen Dank im Voraus ;)
Ansonsten gibt es die "timer" Alternativ
https://www.linux.com/tutorials/setting-timer-systemd-linux/
Wie wird denn debmatic auf euren Systemen gestartet!?
Auch als systemd Dienst!?
Dann kann man auch eine Abhängigkeit einbauen...
Oder wenn man weiß wie der Prozess heißt eine sleep-Warteschreife einbauen bis der debmatic-Prozess läuft...
Timer/Sleep/etc. ist halt immer "Schätzometer"... ;)
Gruß, Joachim
ZitatWie wird denn debmatic auf euren Systemen gestartet!?
Das ist genau die Frage
Es gibt mehrere Sachen, und ich weiss nicht welche die entscheidende ist...
debmatic-hmserver.service/
debmatic-hs485d.service/
debmatic-lighttpd.service/
debmatic-multimacd.service/
debmatic-rega.service/
debmatic-rfd.service/
debmatic-rfd.service/
debmatic-startupfinished.service/
debmatic-updatelgwfirmware.service/
debmatic-updatelgwkey.service/
debmatic.service/
Also... rein vom Name aus: vermutlich ist lighttpd die Weboberfläsche... unrelevant
updatxxxx auch wahrscheinlich unrelevant
Vielleicht kann man eine Abhängigkeit auf "startupfinished" legen? Hätte Sinn, aber ich weiss nicht, ob das richtig ist. Ich habe es noch nicht getestet
Oder eher auf debmaitc.service? Hmmm...
Deswegen war das "delayed start" von Fhem die einfachste (aber bestimmt nicht sauberste) Lösung
Ich habe gerade die Frage an der richtige Stelle gestellt ;)
https://forum.fhem.de/index.php/topic,97295.msg979998.html#msg979998
Das hier funktioniert und started fhem NACH debmatic:
unter [Unit] ist Wants und After mit dem debmatic-startupfinished.service in einer Zeile zu ergänzen.
cat /etc/systemd/system/fhem.service
# $Id: fhem.service 16001 2018-01-26 11:54:41Z betateilchen $
[Unit]
Description=FHEM Home Automation
Wants=network.target debmatic-startupfinished.service
After=network.target debmatic-startupfinished.service
[Service]
Type=forking
User=root
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always
#ExecStartPre=/usr/bin/sleep 300
[Install]
WantedBy=multi-user.target
Hi, würde mich hier gern ranhängen, weil ich fhem ebenfalls nach einem Reboot verzögert starten möchte.
Hintergrund:
auf dem selben System läuft ein zigbee-Gateway (deCONZ), welches nach einem Rebook erst eine Weile für die Initialisierung benötigt und danach alle Endgeräte neu verbinden muss. Das dauert ein paar Minuten.
Bisher startet mein fhem sofort, kann sich dann zu diesem Gateway nicht verbinden und diverse Sensoren & Aktoren laufen nicht. Ich muss dann jedes Mal manuell einen shutdown restart durchführen, bis es rennt.
Zitat von: amenomade am 02 Oktober 2019, 15:29:55
Ansonsten gibt es die "timer" Alternativ
https://www.linux.com/tutorials/setting-timer-systemd-linux/
Bezogen auf dies Zitat hatte ich etwas gegoogelt und folgende detailierte Howto-Anleitung gefunden ( https://forum.smartapfel.de/forum/thread/903-verzögerter-homebridge-start-nach-reboot-empfehlenswert-bei-der-nutzung-vom-rasp/ ) die ich als Linux-Laie hinbekommen würde.
Kann ich diese Anleitung für den FHEM-Service 1:1 übernehmen ?
Zitat von: schwatter am 02 Oktober 2019, 10:32:54
Habe Debmatic noch nicht wirklich getestet. Aber du möchtest Fhem verzögern, daher sollte das so funktionieren.
nano /etc/systemd/system/fhem.service
Und das eintragen, was du unter Punkt 2 geschrieben hast.
# $Id: fhem.service 19235 2019-04-21 13:26:17Z betateilchen $
[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target
#Requires=postgresql.service
#After=postgresql.service
#Requires=mysql.service
#After=mysql.service
[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always
ExecStartPre=/bin/sleep 120
[Install]
WantedBy=multi-user.target
Hallo!
Ich habe dies mal getestet... Leider startet Fhem gar nicht wen ich diese Zeile dort einfüge... Woran könnte es liegen?
Wenn ich dann versuche manuell FHEM zu starten bekomme ich eine Fehlermeldung.
pi@raspberrypi:~ $ sudo sudo service fhem status
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start-pre) since Sun 2022-02-06 10:21:02 CET; 11s ago
Cntrl PID: 3884 (sleep)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─3884 /bin/sleep 120
Feb 06 10:21:02 raspberrypi systemd[1]: Starting FHEM Home Automation...
pi@raspberrypi:~ $ sudo sudo service fhem status
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start-pre) since Sun 2022-02-06 10:22:33 CET; 9s ago
Cntrl PID: 3977 (sleep)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─3977 /bin/sleep 120
Feb 06 10:22:33 raspberrypi systemd[1]: Starting FHEM Home Automation...Musste erst die Zeile wieder löschen.... Danach hat Fhem wieder gestertet...
120 sec überschreiten den Timeout von systemd.
Zusätzlich muss in dem Fall die Zeile
TimeoutStartSec=130
eingefügt werden
Der Standardwert liegt bei 90 sec. Anzeigen mit:
systemctl show fhem.service -p TimeoutStartUSec
Ich habe es im Wiki (https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)#Start_verz.C3.B6gern)ergänzt.
Gruß Otto
Das ist es! Klasse! Vielen Dank!
ich bin unsicher, ob die Reserve von 10 sec ausreicht. Ich weiß nicht wann systemd den fhem Service als "start erfolgreich" ansieht. Kann sein das passiert sehr schnell wegen forking, kann sein eine ungünstige Konstellation (blocking Aufrufe beim start) benötigt mehr Zeit.
Müsste man also ev. nachjustieren.
Wäre es nicht "sauberer" eine Abhängigkeit zu benötigten Services "einzubauen"?
Und wenn man von einem "nicht-Service" abhängt, dann kann/könnte man doch dafür (also für die benötigte Abhängigkeit) einen "pseudo-Dienst" anlegen...
Habe das für fhem (bei einem Kumpel) bzgl. deCONZ und Internet (da hing ein LTE-USB-Stick dran) "gebastelt"...
Zeitverzögerungen haben immer das Problem der "Schätzung" ;)
Gruß, Joachim
Auf alle Fälle, so eine Lösung steht ja in #8 - warum misux diese Lösung nicht nachgebaut hat?
Ich baue einfach eine Reserve von 30 Sekunden ein. Das reicht denke ich... Das mit den 10 hat ja schon mal geklappt...
Ich finde einige Dinge müssen auch mal etwas einfacher sein... und in diesem Fall ist das einfach und tut seinen Dienst. Und wenn es ne Minute länger daueret ist das auch nicht schlimm. So viel Zeit darf auch mal sein.
Das andere ist genauso einfach...
Stichworte: Wants, After, Requires
Dort die Abhängigkeit(en) eintragen -> done
Funktioniert selbst wenn sich Startzeiten etc. ändern und "verzögern" nur so viel wie tatsächlich nötig...
Gruß, Joachim
Also ich mache es wegen der piVccu die recht lange braucht bis sie 1. gestartet ist und 2. auch die Verbindung zu den Aktoren aufgenommen hat. Wenn das passiert ist erst dann Startet meine HMCCU und HMCCURPCPROC zuverlässig im Fhem wenn Fhem Schneller ist und das ist es meistens gibt es nur Probleme und ich muss fhem Manuell neustarten...
Zitat von: MadMax-FHEM am 06 Februar 2022, 19:44:44
Das andere ist genauso einfach...
Stichworte: Wants, After, Requires
Dort die Abhängigkeit(en) eintragen -> done
Funktioniert selbst wenn sich Startzeiten etc. ändern und "verzögern" nur so viel wie tatsächlich nötig...
Gruß, Joachim
Naja, einfach ist es wenn man weiß wovon man spricht... ;D ich bin froh das das erstmal geklappt hat... :-X Ich wüsste nciht was ich eintragen muss damit fhem erst startet wenn piVccuauch wirklich fertig ist...
Vielleicht hast du einen heißen Tipp? :-*
Bin an sich für besseres sowieso immer zu haben..
Wie von Otto schon genannt: #8
EDIT: statt debmatic halt der piVCCU Service. Wie der heißt: keine Ahnung, da ich das nicht habe...
Gruß, Joachim