Ich verwende einen Raspberry Pi 3 und muss die Uhrzeit nach dem Neustart des Systems über NTP aktualisieren.
Es sollte über WLAN mit DHCP aktualisiert werden. Im Allgemeinen funktioniert es, aber die Synchronisation dauert ca. eine halbe Stunde und ich verstehe nicht warum.
Wenn ich den ntp-Dienst manuell mit
starten möchte>>sudo /etc/init.d/ntp restart
Es sagt „ok“, aber das System tut nichts – die RTC zeigt immer noch die falsche Zeit an.
Haben Sie eine Idee, was das Problem sein könnte?
Eine weitere Information ist, dass der Pi im Nur-Lese-Modus läuft… aber wenn er ohne Schreibzugriff nicht funktioniert, würde er nach einer halben Stunde nicht aktualisiert werden, oder?
Weitere Einzelheiten:
Um mein Problem zu vervollständigen, hier die ntp.conf:
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
Driftfile /var/lib/ntp/ntp.drift
Statistics loopstats peerstats clockstats
Filegen loopstats file loopstats type day enable
Filegen peerstats file peerstats type day enable
Filegen clockstats file clockstats type day enable
...
Server 0.de.pool.ntp.org iburst
Server 1.de.pool.ntp.org iburst
Server 2.de.pool.ntp.org iburst
Server 3.de.pool.ntp.org iburst
Server 127.127.1.0 #local clock
Fudge 127.127.1.0 stratum 10
...
Um meine Erklärung zu meinem Projekt zu erweitern. Ich möchte den Pi als NTP-Server verwenden. Das erste Problem war, dass die RTC nach einem Neustart oder beim Ausschalten des Pi „wegläuft“ – vor allem für längere Zeit. Deshalb hatte ich die Idee, dass der Pi beim ersten Mal ein NTP-Client sein sollte, um die RTC zu setzen und danach der Pi ein NTP-Server für das Gerät sein muss, das über Ethernet mit dem Pi verbunden ist. Also habe ich den Pi über Wifi verbunden, um die aktuelle Uhrzeit zu bekommen. Wie gesagt, grundsätzlich funktioniert es, aber es dauert zu lange.
Dann wollte ich die Synchronisation manuell mit diesem Befehl machen, den ich zuvor gepostet habe. Meine Idee war, dies als Cronjob zu tun, aber es gibt das nächste Problem:1. der Pi hat den Befehl ignoriert; 2. Der Cronjob wird ebenfalls ignoriert oder nach einem Neustart gelöscht.
Aber ich möchte Schritt für Schritt vorgehen und das erste Problem, das ich lösen möchte, ist die Verringerung der Synchronisierungszeit.
Ich hoffe, Sie haben jetzt einen besseren Überblick über meine Situation….
Benötigen Sie weitere Informationen?
NEUE INFORMATIONEN:01.02.2018
Okay, also habe ich jetzt die Lösung, die ich will, ABER es gibt ein Verhalten, das ich nicht verstehe. Die Konfigurationen waren korrekt.
Allerdings nutze ich das Onboard-WLAN, um die Systemzeit über einen NTP-Server zu synchronisieren, den ich in der ntp.conf konfiguriert habe. Ich verwende das Ethernet (kabelgebundenes LAN) als NTP-Server für das kabelgebundene Gerät zum RPi. Hier die IP-Einstellungen:
WLAN (DHCP): 192.168.1.x
Ethernet (static): 192.168.10.10
Ich habe beide Interfaces in unterschiedliche Netzwerke gesteckt, weil sonst nur eine Verbindung funktionieren würde – aber warum eigentlich?
Und das ist das Hauptproblem, warum die Synchronisation so lange gedauert hat. Wenn ich die Zeile mit der lokalen Uhr auskommentiere
Server 127.127.1.0
Dann funktioniert die Synchronisation über das Netzwerk sofort…
Warum passiert das?
Akzeptierte Antwort:
Das rpi hat keine RTC und bootet daher immer am 1. Januar 1970 – die Zeit, um den Server und NTP langsam und inkrementell zu synchronisieren, ist größer; daher beginnt NTP standardmäßig nicht normal zu arbeiten, bis der Unterschied zwischen NTP und dem System korrigiert wird.
Ich würde zu Ihrer ntp.conf hinzufügen Datei als erste Zeile (es muss die erste Zeile sein):
tinker panic 0
Diese Einrichtung wird für die VMs und empfohlen iOTs-Geräte.
Bastelpanik – Gibt die Panikschwelle in Sekunden an, standardmäßig
1000 s. Wenn auf Null gesetzt, wird die Panic Sanity Check deaktiviert und ein Clock-Offset
eines beliebigen Werts wird akzeptiert.
Ich würde auch den Kauf einer RTC in Betracht ziehen, da sie billig ist, insbesondere wenn Sie beabsichtigen, Projekte ohne Internetverbindung zu haben. siehe hwclock kann rtc-Datei nicht öffnen