[gelöst] Installation RasPi -NTP-

Begonnen von Mundus, 18 April 2017, 09:50:55

Vorheriges Thema - Nächstes Thema

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

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

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

Morgennebel

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
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Mundus

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.

Otto123

#6
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 
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

Morgennebel

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
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Mundus

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


Otto123

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

Mundus

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

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
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Mundus

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

Otto123

#13
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
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

krikan

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

Verzeichnis angelegt:
/etc/systemd/system/fhem.service.d

Darin Datei fhem.conf mit folgendem Inhalt angelegt:
[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.  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