[Lösung]
Zur Änderung der Startreihenfolge "ntp vor fhem" auf dem Raspberry Pi (Betriebssystem Raspbian Jessie Lite) habe ich folgendes erfolgreiches Vorgehen gewählt:
1. mit sudo ein neues Verzeichnis unter /etc/systemd/system anlegen
sudo mkdir /etc/systemd/system/fhem.service.d
2. eine Datei im neu erstellten Verzeichnis anlegen (wichtig ist, dass die Datei auf conf endet)
sudo vi /etc/systemd/system/fhem.service.d/fhem.conf
3. in die Datei die folgenden drei Zeilen eintragen und anschließend Datei speichern
[unit]
Wants=ntp.service
After=ntp.service
4. Neustart des RasPi und überprüfen der Status
sudo reboot
systemctl status ntp.service
systemctl status fhem.service
Nunmehr dürfte der ntp.service vor dem fhem.service seine Arbeit begonnen haben. Die WarnmeldungWarning: Unit file changed on disk, 'systemctl daemon-reload' recommended. beim Status des fhem.service kann ignoriert werden. Diese ist ein Bug von systemd Version 215 und wurde mit der Version 230 bereits behoben.
################################
Hallo,
bei meiner Neuinstallation (Systemumzug) bin ich auf den folgenden Hinweis https://wiki.fhem.de/wiki/Raspberry_Pi#Echtzeituhr (https://wiki.fhem.de/wiki/Raspberry_Pi#Echtzeituhr) aufmerksam geworden und habe in den LOGS gesehen, dass ntp als letzter Service gestartet wird und somit erst nach FHEM zur Verfügung steht.
Bei meiner weiteren Recherche -wie ändere ich die Reihenfolge des Starts der Services- habe ich viele Artikel gelesen und festgestellt, dass nicht mehr alle Artikel aktuell sind.
Letztendlich habe ich diesen Artikel https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units (https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units) als Hilfreich empfunden und plane mittels
sudo systemctl edit -full fhem.service im Abschnitt [Unit] folgendes einzutragen:
Requieres=ntp.service
die Abhängigkeit beim Start meines Raspi3 zu beeinflussen.
Da ich aber bereits eine Vielzahl an Artikeln gelesen habe und bei min. einem den Hinweis las, dass "Wait" bzw. "Requieres" nicht verwandt werden soll, die Frage:
Ist der Weg richtig? Gibt es negative Seitenfeffekte oder einen anderen Weg?
Gruß
Mundus
Hi Mundus,
Ich kann dir deine Frage nicht beantworten, aber ein andere Hinweis in dieser Sache:
Ich habe in jedem meiner FHEM Raspberrys einen RTC Chip nachgerüstet:
http://www.raspberry-pi-geek.de/Magazin/2015/03/Echtzeituhr-Modul-DS3231-sorgt-fuer-genaue-Zeitangaben
Damit umgehst Du das ganze Problem der Systemuhrzeit.
Grüße
Frank
Zitat von: Mundus am 18 April 2017, 09:50:55
bei meiner Neuinstallation (Systemumzug) bin ich auf den folgenden Hinweis https://wiki.fhem.de/wiki/Raspberry_Pi#Echtzeituhr (https://wiki.fhem.de/wiki/Raspberry_Pi#Echtzeituhr) aufmerksam geworden und habe in den LOGS gesehen, dass ntp als letzter Service gestartet wird und somit erst nach FHEM zur Verfügung steht.
Hallo!
Gibt es tatsächlich Probleme mit der Uhrzeit in FHEM?
FHEM kontrolliert in aktuellen Versionen afaik ob die Uhrzeit gesetzt ist. Falls nicht, wartet FHEM und es gibt auch einen Log-Eintrag "date/time not set, waiting up to 2 hours to be set".
Gruß, Christian
Hatte bislang nur Probleme, wenn der Strom hart weg war und dann wieder kam, da der Router etwas braucht, bis er wieder Internet hat und somit der ntp beim Booten (geht ja schneller als der Router wieder Internet hat) keinen ntp-Server gefunden hat.
Danach war es meist nicht so gut....
...aber ein Reboot des PI und alles war wieder ok, da ja dann der Router Internet hatte...
Ansonsten keine Probleme wegen Startreihenfolge der Dienste etc.
Gruß, Joachim
Zitat von: krikan am 18 April 2017, 10:27:36
Gibt es tatsächlich Probleme mit der Uhrzeit in FHEM?
FHEM kontrolliert in aktuellen Versionen afaik ob die Uhrzeit gesetzt ist. Falls nicht, wartet FHEM und es gibt auch einen Log-Eintrag "date/time not set, waiting up to 2 hours to be set".
Ja.
Nach jedem Absturz hat mein ODROID eine Systemzeit von 2000-01-01 00:00 und füllt die Logfiles mit %Y entsprechend. Irgendwann ändert der NTP die Uhrzeit und einige DOIFs/notifies werden abgearbeitet. Das hat zur Folge, daß manchmal nach einem Absturz die Lampen im Haus blinken, der Staubsauger-Roboter losfährt und es einige Minuten dauert, bis sich alles beruhigt hat...
Ciao, -MN
Zitat von: krikan am 18 April 2017, 10:27:36
Gibt es tatsächlich Probleme mit der Uhrzeit in FHEM?
Hi, dass weiß ich natürlich nicht, habe aber derzeit Probleme mit meinem ZWave-Netz und dem alten (langsamen) RaPi und will daher mögliche Fehlerquellen ausschließen. Die Aussage von Morgennebel scheint mich auch glauben zu lassen, dass es evtl. zu Problemen kommen kann.
Ist der von mir beschriebene Weg den richtig und nutzt diesen jemand?
Gruß
Mundus
P.S.: Sollte das Problem mit dem Zeitserver gelöst sein, so sollte evtl. der Wiki-Hinweis entfernt werden.
Hi Mundus,
ich verwende das (allerdings im init.d Script sollte aber egal sein). Es gibt nach meiner Erfahrung beim Pi3 das Problem, dass FHEM unter Umständen nach einem Neustart 100% Last verursacht und damit quasi nach außen hin nicht läuft / Web nicht erreichbar ist. Seitdem ich die Startabhängigkeit vom ntp (und damit netzwerk) einrichte ist mir das nie wieder passiert. Was das ursächliche Problem wirklich ist, kann ich nicht sagen.
Das ntp gestartet ist, bedeutet nicht zwangsläufig, dass er auch die Zeit gestellt hat.
Das beschriebene Problem von Morgennebel dürfte beim Raspberry nicht auftreten, da bei ihm standardmäßig fake-hwclock läuft und somit die Systemuhr zumindest nicht bei einem Uraltdatum sondern mit dem letzten Datum des letzen Schreibens von fake-hwclock startet.
Damit wird die Zeit fortlaufend, man muss nur bei system logs interpretieren ob die Startzeit jetzt die Echtzeit war oder die bevor irgendwas schlimmes passiert war.
Gruß Otto
Zitat von: Mundus am 18 April 2017, 09:50:55
Da ich aber bereits eine Vielzahl an Artikeln gelesen habe und bei min. einem den Hinweis las, dass "Wait" bzw. "Requieres" nicht verwandt werden soll, die Frage:
Ist der Weg richtig? Gibt es negative Seitenfeffekte oder einen anderen Weg?
Systemd startet das System nicht-deterministisch, es werden nur Abhängigkeiten angegeben. Du änderst eine Abhängigkeit mit den vorgegebenen Werkzeugen - da sollte nicht viel passieren können. Versuch macht klug.
Eine Alternative wäre eine Systemd-freie Linux-Distribution, in der Du die Start-Reihenfolge fest vorgeben kannst - das führt aber zu einem Glaubenskrieg unter den Linux-Jüngern :) Falls es Dich diese Lösung interessiert, schau mal hier: https://devuan.org/ mit Unterstützung für den Pi. Bedenke aber, daß die Userbasis sehr viel kleiner ist und Du mit anderen Problemen weniger Hilfe erwarten kannst...
Ciao, -MN
Zitat von: Morgennebel am 18 April 2017, 11:47:08
Systemd startet das System nicht-deterministisch, es werden nur Abhängigkeiten angegeben. Du änderst eine Abhängigkeit mit den vorgegebenen Werkzeugen - da sollte nicht viel passieren können.
Ich habe es gerade ausprobiert, es passiert nichts (mehr). Der Dienst wird leider nicht gestartet (inactive (dead)). Irgendetwas mache ich wohl falsch... Vielleicht könnt ihr mir helfen?
Da die edit-Funktion bei systemd (Version 215) noch nicht umgesetzt ist, habe ich mittels cp die Datei aus /run/systemd/gerator.late/ nach /etc/systemd/system kopiert und dort die Zeile
Requires=ntp.service
hinzugefügt.
Leider wird der Dienst dann nicht gestartet. Ist es evtl. noch erforderlich notwendige Links manuell zu setzen oder muss ich noch die Zeile after um ntp.service ergänzen?
Zitat von: Otto123 am 18 April 2017, 11:32:07
...ich verwende das (allerdings im init.d Script sollte aber egal sein).
Wie sieht deine Lösung aus?
Gruß
Mundus
Hi,
wie gesagt ich habe an der Standardinstallation nichts weiter verändert. Außer:
# Den Systemstart von ntp abhängig machen
sed -i s/'# Required-Start: $local_fs $remote_fs/# Required-Start: $local_fs $remote_fs $ntp/' /etc/init.d/fhem
systemctl daemon-reload
Du kannst natürlich auch per Hand editieren, ich installiere aber immer per Script.
Gruß Otto
Hmmm,
das habe ich jetzt probiert und folgendes finde ich im Daemon.log
Apr 18 23:07:29 FhemRaspi3 fhem[404]: Starting fhem...
...
Apr 18 23:07:30 FhemRaspi3 systemd[1]: Started LSB: FHEM server.
...
Apr 18 23:07:38 FhemRaspi3 systemd[1]: Started LSB: Start NTP daemon.
Apr 18 23:07:38 FhemRaspi3 ntp[688]: Starting NTP server: ntpd.
zudem finde ich im Log von FHEM folgendes
017.04.18 23:07:36 0: Server started with 9 defined entities (fhem.pl:13447/2017-02-19 perl:5.020002 os:linux user:fhem pid:592)
Zumindest nach dem Zeitstempel ist fhem immer noch vor dem ntp gestartet... Da meine Linux-Kenntnisse weit weg von gut sind, die Frage, ist meine Interpretation richtig? Otto, sehen deine Logs auch so aus?
Gruß
Mundus
Hi Mundus,
soweit ich mich erinnere, startet systemd die Dienste in der Reihenfolge. Braucht aber ein Dienst sehr lange zum initialisieren (wie fhem) kann ein anderer schon fertig sein.
Deine Lösung könnte "After" statt "Requires" sein: http://stackoverflow.com/questions/21830670/systemd-start-service-after-specific-service
Für mich persönlich sind dies die Gründe gewesen, systemd aus meiner IT Infrastruktur zu verbannen :)
Ciao, -MN
Zitat von: Mundus am 19 April 2017, 00:07:23
...
das habe ich jetzt probiert und folgendes finde ich im Daemon.log
...
Damit meinte ich die Lösung von
Zitat von: Otto123 am 18 April 2017, 22:22:53
...
Du kannst natürlich auch per Hand editieren, ich installiere aber immer per Script.
...
Scheint bei mir nicht den gewünschten Erfolg zu bringen. Werde daher erneut versuchen die
Zitat von: Mundus am 18 April 2017, 22:09:45
...
cp die Datei aus /run/systemd/gerator.late/ nach /etc/systemd/system kopiert und dort die Zeile
Requires=ntp.service
hinzugefügt...
Werde zudem die Formulierung
Requires=ntp.target und
After=ntp.service bzw. After=ntp.target probieren. Der Unterschied zwischen target und service ist mir nicht ganz klar, auch das Lesen der vielen Seiten hat nicht zu meiner Erhellung beigetragen ;).
Gruß
Mundus
Hi,
so theoretisch habe ich das nie betrachtet :) Ich habe das gemacht weil es die Empfehlung war und es hat scheinbar funktioniert.
Aber ja es sieht bei mir ähnlich aus, was das in Praxis konkret bedeutet?
ntp.service - LSB: Start NTP daemon
Loaded: loaded (/etc/init.d/ntp)
Active: active (running) since Fri 2017-04-07 09:55:02 CEST; 1 weeks 5 days ago
Process: 733 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/ntp.service
└─759 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.c...
pi@raspib3:~ $ systemctl status fhem
● fhem.service - LSB: FHEM server
Loaded: loaded (/etc/init.d/fhem)
Active: active (running) since Fri 2017-04-07 09:54:56 CEST; 1 weeks 5 days ago
Anderes System mit der Änderung (# Required-Start: $local_fs $remote_fs $ntp):● fhem.service - LSB: FHEM server
Loaded: loaded (/etc/init.d/fhem)
Active: active (running) since Di 2017-04-18 10:17:13 CEST; 1 day 7h ago
Process: 394 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/fhem.service
└─470 perl fhem.pl fhem.cfg
pi@raspi0w:~ $ systemctl status ntp
● ntp.service - LSB: Start NTP daemon
Loaded: loaded (/etc/init.d/ntp)
Active: active (running) since Di 2017-04-18 10:17:18 CEST; 1 day 7h ago
Process: 601 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/ntp.service
└─622 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.c...
Ohne Änderung (# Required-Start: $local_fs $remote_fs)
pi@raspi0w:~ $ systemctl status fhem
● fhem.service - LSB: FHEM server
Loaded: loaded (/etc/init.d/fhem)
Active: active (running) since Mi 2017-04-19 17:32:51 CEST; 37s ago
Process: 394 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/fhem.service
└─510 perl fhem.pl fhem.cfg
pi@raspi0w:~ $ systemctl status ntp
● ntp.service - LSB: Start NTP daemon
Loaded: loaded (/etc/init.d/ntp)
Active: active (running) since Mi 2017-04-19 17:32:57 CEST; 39s ago
Process: 638 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/ntp.service
└─661 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.c...
Dann war es wie mit guter Medizin, mann muss dran glauben.
Gruß Otto
Habe es mit einer drop-in-Datei einmal ausprobiert:
Verzeichnis angelegt:
/etc/systemd/system/fhem.service.dDarin Datei fhem.conf mit folgendem Inhalt angelegt:
[Unit]
Wants=ntp.service
After=ntp.serviceWants statt Requires habe ich aufgrund der man-page-Erläuterung zu Requires https://www.freedesktop.org/software/systemd/man/systemd.unit.html# ausgewählt. Daraus ergibt sich auch, dass neben Requires/Wants die Startreihenfolge per Before/After festgelegt werden muss.
Habe das ein paar Mal getestet und Startreihenfolge war immer -zumindest in den Tests- wie gewünscht; zuerst ntp und dann FHEM.
ABER: Da ich eigentlich WinUser bin, ist das nicht unbedingt die richtige und eine sinnvolle Lösung. 8)
ZitatFHEM kontrolliert in aktuellen Versionen afaik ob die Uhrzeit gesetzt ist. Falls nicht, wartet FHEM und es gibt auch einen Log-Eintrag "date/time not set, waiting up to 2 hours to be set".
Laut Code-Kommentierung in fhem.pl ist das ein fritzbox-Spezial. Also beim Raspi (und anderen Systemen) wohl nicht einschlägig.
Gruß, Christian
Zitat von: krikan am 19 April 2017, 22:32:46
Habe es mit einer drop-in-Datei einmal ausprobiert:
...
Habe das ein paar Mal getestet und Startreihenfolge war immer -zumindest in den Tests- wie gewünscht; zuerst ntp und dann FHEM.
...
Ich habe jetzt den selben Weg gewählt und es bringt zumindest den Erfolg, dass laut Status-Meldung die Startreihenfolge richtig zu sein scheint. Habe nur nun das Problem, dass ich eine "Fehlermeldung" erhalte:
Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.. Diese verschwindet auch nicht...(Naja, sobald ich den gewünschten Befehl ausführe wird die Meldung nicht mehr angezeigt, Ich kann natürlich in die rc.local den Befehl aufnehmen, aber das ist IMHO nicht die Lösung des Problems.)
Ich habe auch den Verdacht, dass ich die Fehlermeldung wahrscheinlich ignorieren kann, aber auch dies scheint nicht die perfekte Lösung, oder?
Die Status-Meldungen sehen derzeit wie folgt aus
systemctl status fhem.service
● fhem.service - LSB: FHEM server
Loaded: loaded (/etc/init.d/fhem)
Drop-In: /etc/systemd/system/fhem.service.d
└─fhem.conf
Active: active (running) since Thu 2017-04-20 21:20:23 CEST; 1h 8min ago
Process: 728 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/fhem.service
└─737 perl fhem.pl fhem.cfg
Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
und
systemctl status ntp.service
● ntp.service - LSB: Start NTP daemon
Loaded: loaded (/etc/init.d/ntp)
Active: active (running) since Thu 2017-04-20 21:20:22 CEST; 1h 35min ago
CGroup: /system.slice/ntp.service
└─727 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 106:111
Der Ansatz ist IHMO korrekt, würde aber gerne die Warnmeldung noch abschalten.
Gruß
Mundus
Die dauernde Anzeige von
ZitatWarning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
bei drop-ins ist nach https://github.com/systemd/systemd/issues/3123 ein Bug in systemd der mit Version 230 behoben wurde. raspbian nutzt derzeit (systemd --version) Version 215.
Funktional hat die Anzeige wohl keine Auswirkungen.
Ich habe den Thread jetzt auf gelöst gesetzt. Ist es sinnvoll den ersten Artikel zu editieren und die Lösung dort zu Beginn aufzuführen? Hierbei würde ich die Lösung von krikan (vielen Dank an dieser Stelle) Schritt für Schritt aufschreiben und den Hinweis mit der Warnmeldung aufnehmen.
Gruß
Mundus
Zitat von: Mundus am 21 April 2017, 13:54:18
Ich habe den Thread jetzt auf gelöst gesetzt. Ist es sinnvoll den ersten Artikel zu editieren und die Lösung dort zu Beginn aufzuführen? Hierbei würde ich die Lösung von krikan (vielen Dank an dieser Stelle) Schritt für Schritt aufschreiben und den Hinweis mit der Warnmeldung aufnehmen.
Gruß
Mundus
Wenn du kurz beschreibst welche Schritte du ausgeführt hast wäre das natürlich Hammer ... vor allem weil ich die nächsten Tage mein Fhem auf RPI3 umziehen möchte :)
Hast du, hat jemand NTP auch abgesichert? Ich meine Anleitung wie diese ... http://wiki.euserv.de/index.php/Absicherung_von_NTP (http://wiki.euserv.de/index.php/Absicherung_von_NTP)? Auch wenn die meisten FHEM nur lokal betreiben hängen doch manche im Internet. Will keine Panik verbreiten, aber wenn man sich schon die Arbeit macht. Für den Fall, dass ich NTP in mein Setup-Script mit aufnehme kann ich es auch beisteuern.
Die Schritte mit im WiKi wären sicher für viele hilfreich.
Ich würde aber auch die Möglichkeit des RTC Moduls für den RasPi erwähnen. damit wäre das alles hinfällig. :-)
Dieser Forenthread ist im Wiki an der oben von Mundus genannten Stelle bereits seit 3 Tagen verlinkt. Das sollte mMn fürs FHEM-Wiki reichen.
Zitat von: Frank_Huber am 21 April 2017, 15:34:05
Ich würde aber auch die Möglichkeit des RTC Moduls für den RasPi erwähnen. damit wäre das alles hinfällig. :-)
Wieso? Was hat die Thematik damit zu tun?
Hier geht es darum den fhem Service nach einem anderen Systemdienst zu starten. Das der ntp Dienst läuft, heißt nicht zwangsläufig das er auch die Zeit gestellt hat. Das man eine RTC hat, heißt nicht zwangsläufig das die Zeit stimmt.
Gruß Otto
Na mit rtc hast das Uhrzeit Problem nicht mehr. Das hält ja dann die Uhrzeit wenn der Strom weg ist. Und ist deutlich weniger Aufwand als die Dienste umzuziehen. ;-)
Gesendet von meinem JY-S3 mit Tapatalk
Zitat von: Frank_Huber am 21 April 2017, 21:30:26
Na mit rtc hast das Uhrzeit Problem nicht mehr. Das hält ja dann die Uhrzeit wenn der Strom weg ist. Und ist deutlich weniger Aufwand als die Dienste umzuziehen. ;-)
Gesendet von meinem JY-S3 mit Tapatalk
Sorry aber das ist Unsinn.
Ne, kein Blödsinn, einfach nur eine weitere Möglichkeit. Für mich sogar die bessere. Weil was ist wenn der ntp nicht erreichbar ist? Mit rtc ists egal.
Gesendet von meinem JY-S3 mit Tapatalk
Ich habe jetzt eine Zusammenfassung in meinem ersten Beitrag aufgenommen. Hoffentlich ist diese verständlich und hilft auch anderen NutzerInnen weiter.
Vielen Dank für eure Unterstützung und Mühen.
Zitat von: kadettilac89 am 21 April 2017, 14:36:54
Hast du, hat jemand NTP auch abgesichert?
Nein habe ich nicht, du kannst die ntp.conf aber auch so verändern, dass die Zeit bei einem internen Zeitserver z.B.: FritzBox abgefragt wird.
Zitat von: Frank_Huber am 21 April 2017, 15:34:05
Ich würde aber auch die Möglichkeit des RTC Moduls für den RasPi erwähnen. damit wäre das alles hinfällig. :-)
Das RTC-Modukl habe ich nicht erwähnt, da in meinem Falle die GPIO bereits belegt sind und diese Möglichkeit daher für mich ausscheidet.
Gruß Mundus
Zitat von: Mundus am 18 April 2017, 09:50:55
[Lösung]
Zur Änderung der Startreihenfolge "ntp vor fhem" auf dem Raspberry Pi (Betriebssystem Raspbian Jessie Lite) habe ich folgendes erfolgreiches Vorgehen gewählt:
1. mit sudo ein neues Verzeichnis unter /etc/serviced/service anlegen
sudo mkdir /etc/serviced/service/fhem.service.d
2. eine Datei im neu erstellten Verzeichnis anlegen (wichtig ist, dass die Datei auf conf endet)
sudo vi /etc/serviced/service/fhem.service.d/fhem.conf
Danke für den Thread, der mir beim Aufsetzen meines neuen RasPi3 (auch) weitergeholfen hat.
Aber ich denke in den Zeilen 1. und 2. hat sich der Tipp-Teufel eingeschlichen - müsste doch jeweils "/etc/systemd/system..." und nicht "service" heißen. Ist zumindest bei mir und in Antwort 14 so ;) (https://forum.fhem.de/index.php/topic,70741.msg623150.html#msg623150).
Gruß
Claus
Zitat von: clapele am 01 Mai 2017, 12:28:11
Aber ich denke in den Zeilen 1. und 2. hat sich der Tipp-Teufel eingeschlichen - müsste doch jeweils "/etc/systemd/system..." und nicht "service" heißen...
Stimmt, da hat sich der Fehlerteufel eingeschlichen, ist aber nun behoben.
Gruß
Mundus
Hey mundus,
sudo mkdir /etc/serviced/system/fhem.service.d
ist immer noch falsch.
Richtig wäre:
sudo mkdir /etc/systemd/system/fhem.service.d
Fällt aber auf, wenn man versucht den Code einzugeben ::)
MM