Ich kann auf einige dieser Punkte eingehen, einschließlich des Titels.
[...] die immer mit systemd-timesyncd korrelieren Aktualisierung der Systemuhr. Damit meine ich, dass die allererste Syslog-Meldung nach einem Zeitsprung eine Time has been changed ist Syslog-Meldung:
grep 'Time has been changed' /var/log/syslog
Oct 2 23:53:33 hostname systemd[1]: Time has been changed
Eigentlich sagt Ihnen diese Meldung nicht, welches Programm den Zeitsprung verursacht hat. Es ist nur ein Symptom des Zeitsprungs.
Es passiert, wenn der Kernel systemd mitteilt die Uhr wurde umgestellt.[*] systemd antwortet, indem es diese Nachricht in das Systemprotokoll schreibt und dann neu berechnet, wenn .timer Einheiten müssen ausgelöst werden.
Die Nachricht wird vom Programm systemd gedruckt , nicht von systemd-timesyncd .
Genauer gesagt bedeutet das Nachrichtenpräfix „systemd[1]:“, dass es von Prozess-ID 1 kommt. PID 1 ist der spezielle „init“-Prozess. Das systemd-Projekt nennt dies auch den "Systemmanager", um es von Instanzen von systemd zu unterscheiden die Benutzerdienste verwalten.
Das Programm namens systemd ändert die Uhr nicht, nachdem das System hochgefahren ist.
Im aktuellen systemd-Quellbaum, auf den Sie verlinken, ist das einzige Programm, das die RTC / Hardwareuhr / hwclock überhaupt liest, timedated , und nur, wenn Sie es mit timedatectl abfragen .
Soweit ich mich erinnere, ältere Versionen des systemd Das Programm liest die hwclock einmal beim Booten, bevor es ein anderes Programm ausführt, und stellt die Systemuhr entsprechend ein. In der neusten Version systemd tut dies nicht. Es gibt nur ein paar Hackereien, die dem Kernel sagen, welche Zeitzone wird für die Hardware-Uhr verwendet. (Und vermeiden, etwas sehr Spezifisches namens "Time Warp" auszulösen).
Mit anderen Worten, aktueller systemd scheint implizit davon auszugehen, dass etwas anderes die Systemuhr initialisiert. In den meisten Fällen wird dies der Kernel sein.
Schlagen Sie die Kernel-Build-Option „Systemzeit von RTC beim Start festlegen und fortsetzen“ nach – CONFIG_RTC_HCTOSYS .
Beachten Sie zum besseren Verständnis, dass es auch eine Option „RTC-Zeit basierend auf NTP-Synchronisation einstellen“ gibt – CONFIG_RTC_SYSTOHC .
[*] Änderungen der Systemuhr werden mithilfe einer Linux-spezifischen Funktion erkannt. Siehe TFD_TIMER_CANCEL_ON_SET .
Vielen Dank an sourcejedi für diese Antwort. Das hat mich wirklich dazu gebracht, die richtige Antwort zu finden.
Antwort auf die Frage
Wie verwendet Linux eine Echtzeituhr, um die Systemuhr aufrechtzuerhalten?
Dies geschieht nur einmal während des Bootens. Es wird die RTC bis zum nächsten Neustart nicht erneut abfragen. Dies ist konfigurierbar, wird dies aber bei den meisten Kernel-Builds standardmäßig tun.
Ich möchte wissen, ob ein Fehler mit der Echtzeituhr nur in der Systemuhr auftreten würde, wenn ein timesync-Agent (ntpd oder systemd-timesyncd) aktualisiert wird.
Wenn das System nicht neu gestartet wird, ist es unwahrscheinlich, dass die Zeit in der RTC überhaupt in die Systemuhr gelangt. Einige Agenten wie ntpd kann so konfiguriert werden, dass eine RTC als Zeitquelle verwendet wird, dies ist jedoch normalerweise nicht standardmäßig aktiviert. Es ist nicht ratsam, es zu aktivieren, es sei denn, Sie wissen, dass RTC eine sehr gute Zeitquelle ist.
Gibt es eine direkte Verbindung zwischen der Systemuhr?
Es scheint, dass die Zeit in die andere Richtung kopiert wird. Die RTC wird periodisch mit der Systemzeit aktualisiert. Gemäß der Antwort von sourcejedi wird dies vom Kernel durchgeführt, wenn CONFIG_RTC_HCTOSYS festgelegt ist.
Dies kann getestet werden:
-
Stellen Sie die RTC
ein# hwclock --set --date='18:28' -
Überprüfen Sie dann alle paar Minuten die RTC-Zeit mit:
# hwclock
Das Ergebnis davon ist, dass sich die Systemzeit überhaupt nicht ändert und die RTC schließlich auf die Systemzeit zurückkehrt.
Die Ursache der Zeitsprünge auf der BBB
Wie sourcejedi betonte, wurden die Nachrichten nicht von systemd-timesyncd ausgelöst . Sie wurden durch connman ausgelöst . Der Beweis war (sollte) eine falsche Protokollnachricht in /var/log/syslog :
Oct 3 00:10:37 hostname connmand[1040]: ntp: adjust (jump): -27302612.028018 sec
...
Nov 21 00:07:05 hostname systemd[1]: Time has been changed
Vor Version 1.37 ist connman fest codiert, um das Standard-Gateway für die Zeit zufällig abzufragen. Dazu muss kein DHCP konfiguriert sein und wenn der NTP-Client von connman aktiviert ist (standardmäßig) dann wird es dies unabhängig von jeder anderen Konfiguration tun.
In unserem Fall haben einige Heimrouter tatsächlich auf diese NTP-Anfragen geantwortet, aber die Ergebnisse waren höchst unzuverlässig. Insbesondere bei einem Neustart des Routers hat dieser weiterhin die Uhrzeit ausgegeben, ohne die richtige Uhrzeit zu kennen .
Wir wissen zum Beispiel, dass mindestens eine Version des BT Home Hub 5 beim Neustart standardmäßig den 21. November 2018 anzeigt und dieses Datum über NTP ausgibt. Sein eigener NTP-Client wird das Problem dann beheben, aber es gibt ein Fenster, in dem er den 21. November 2018 ausgibt.
Das heißt, dieses Problem wurde letztendlich dadurch verursacht, dass unsere Kunden ihren Router neu gestartet haben und Connman diese Zeit einfach akzeptiert hat.
Ich werde hier meine Frustration zum Ausdruck bringen, es scheint, dass die Kriegslust einiger dieses "Feature" viel zu lange in Connman gelassen hat. Es wurde bereits 2015 als Problem gemeldet. Und es ist ein wirklich gut verstecktes "Feature". Es sind keine Zeitserver konfiguriert und keine Protokollnachricht, die erklärt, was connman tut, oder eine Dokumentation, warum. Wenn Ihre Test-Rigs keinen NTP-Server auf dem Standard-Gateway haben, werden Sie dies beim Testen nie sehen.
Behebung
Wir sehen uns zwei Optionen an, die beide zu funktionieren scheinen:
-
Connman komplett entfernen. Es scheint, dass das Netzwerk ohne sie gut funktioniert; wir haben den Grund dafür noch nicht gefunden.
apt-get remove connman -
Deaktivieren Sie NTP in Connman, indem Sie
/var/lib/connmanbearbeiten enthalten:[global] TimeUpdates=manual