[gelöst] Installation RasPi -NTP-

[Mundus]

[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

Code Auswählen Erweitern

sudo mkdir /etc/systemd/system/fhem.service.d

2. eine Datei im neu erstellten Verzeichnis anlegen (wichtig ist, dass die Datei auf conf endet)

Code Auswählen Erweitern

sudo vi /etc/systemd/system/fhem.service.d/fhem.conf

3. in die Datei die folgenden drei Zeilen eintragen und anschließend Datei speichern

Code Auswählen Erweitern

[unit]
Wants=ntp.service
After=ntp.service

4. Neustart des RasPi und überprüfen der Status

Code Auswählen Erweitern

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 Warnmeldung

Code Auswählen Erweitern

Warning: 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 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 als Hilfreich empfunden und plane mittels

Code Auswählen Erweitern

sudo systemctl edit -full fhem.service im Abschnitt [Unit] folgendes einzutragen:

Code Auswählen Erweitern

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

[Frank_Huber]

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

[krikan]

bei meiner Neuinstallation (Systemumzug) bin ich auf den folgenden Hinweis 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

[MadMax-FHEM]

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

[Morgennebel]

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

[Mundus]

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.

[Otto123]

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 

[Morgennebel]

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

[Mundus]

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?

...ich verwende das (allerdings im init.d Script sollte aber egal sein).

Wie sieht deine Lösung aus?

Gruß

Mundus

[Otto123]

Hi,

wie gesagt ich habe an der Standardinstallation nichts weiter verändert. Außer:

Code Auswählen Erweitern

# 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

[Mundus]

Hmmm,

das habe ich jetzt probiert und folgendes finde ich im Daemon.log

Code Auswählen Erweitern

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

Code Auswählen Erweitern


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

[Morgennebel]

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

[Mundus]

...
das habe ich jetzt probiert und folgendes finde ich im Daemon.log
...

Damit meinte ich die Lösung von

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

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

Code Auswählen Erweitern

Requires=ntp.target und

Code Auswählen Erweitern

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

[Otto123]

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?

Code Auswählen Erweitern

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):

Code Auswählen Erweitern

● 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)

Code Auswählen Erweitern

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

[krikan]

Habe es mit einer drop-in-Datei einmal ausprobiert:

Verzeichnis angelegt:

Code Auswählen Erweitern

/etc/systemd/system/fhem.service.d

Darin Datei fhem.conf mit folgendem Inhalt angelegt:

Code Auswählen Erweitern

[Unit]
Wants=ntp.service
After=ntp.service
Wants 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. 

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

Laut Code-Kommentierung in fhem.pl ist das ein fritzbox-Spezial. Also beim Raspi (und anderen Systemen) wohl nicht einschlägig.

Gruß, Christian

[Mundus]

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[krikan]

Die dauernde Anzeige von

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

[Mundus]

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

[kadettilac89]

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

[Frank_Huber]

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.

[krikan]

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.

[Otto123]

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

[Frank_Huber]

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

[Otto123]

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.

[Frank_Huber]

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

[Mundus]

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.

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.

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

[Derwodaso]

[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

Code Auswählen Erweitern

sudo mkdir /etc/serviced/service/fhem.service.d

2. eine Datei im neu erstellten Verzeichnis anlegen (wichtig ist, dass die Datei auf conf endet)

Code Auswählen Erweitern

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

[Mundus]

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

[marsmaennchen]

Hey mundus,

Code Auswählen Erweitern

sudo mkdir /etc/serviced/system/fhem.service.d
ist immer noch falsch.
Richtig wäre:

Code Auswählen Erweitern

sudo mkdir /etc/systemd/system/fhem.service.d

Fällt aber auf, wenn  man versucht den Code einzugeben 

MM

[Mundus]

ist immer noch falsch.

geändert und Danke.