☰

Was sind mögliche Gründe für eine fehlerhafte NTP-Synchronisierung?

tag-icon • tag-icon ubuntu ntpd ntp clock
Was sind mögliche Gründe für eine fehlerhafte NTP-Synchronisierung?

Auf einem Ubuntu 10.04-System sind mir die folgenden merkwürdigen NTP-Synchronisierungsereignisse aufgefallen:

Jul  3 02:19:51 hst ntpd[1432]: no servers reachable
Jul  3 02:36:55 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul  3 02:53:48 hst ntpd[1432]: time reset -10.407942 s
Jul  3 02:53:48 hst ntpd[1432]: kernel time sync status change 6001
Jul  3 02:53:48 hst dovecot: dovecot: Fatal: Time just moved backwards by 10 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards
Jul  3 02:58:37 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul  3 02:58:37 hst ntpd[1432]: kernel time sync status change 2001
Jul  3 03:08:15 hst ntpd[1432]: no servers reachable
Jul  3 03:16:49 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul  3 03:17:01 hst CRON[28221]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul  3 03:18:04 hst ntpd[1432]: time reset +10.403648 s
Jul  3 03:22:41 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2

Wobei 91.189.94.4 europium.canonical.com und die einzige Serverzeile darin ntp.confist:

server ntp.ubuntu.com

Das Update um 2:36 Uhr scheint ziemlich falsch zu sein, da es 25 Minuten später abgebrochen wird.

Was könnten mögliche Gründe hierfür sein?

Mir fällt da ein:

  • Der Remote-NTP-Server liefert einfach die falsche Zeit
  • Netzwerkprobleme (könnte eine hohe Latenz solche Abweichungen verursachen?)
  • durch Schaltsekunde verursachter Fehler (das sollte doch stattdessen einen Absturz verursachen, oder?)

Wenn die erste Alternative das Problem war, wie kann ich mich davor schützen?

Ist NTPD intelligent genug, um mehrere NTP-Server abzufragen (wenn mehrere serverLeitungen verfügbar sind ntp.conf) und festzustellen, ob verschiedene Antworten zu stark voneinander abweichen?

Antwort1

Ich habe vor ein paar Jahren solche Syslog-Einträge auf einer Slackware-Maschine gesehen. Ich glaube, ich habe die betreffende Maschine 2002 gekauft und sie jahrelang praktisch rund um die Uhr laufen lassen: Sie war mein SSH-, SMTP- und HTTP-Server. Die NTP-Ausfälle traten langsam auf und wurden allmählich häufiger.

Ich habe das Problem beim ersten Mal behoben, indem ich die „CMOS RAM“-Batterie ausgetauscht habe. Es handelte sich dabei um eine dieser münzgroßen (Vierteldollar-)CR2032-Batterien auf der Hauptplatine.

Nach ein oder zwei weiteren Betriebsjahren war die Uhrzeit auf der Maschine einfach nicht mehr richtig und ich musste sie regelmäßig neu starten ntpd. So wie ich es verstehe, ntpdwird eine „Skew-Datei“ auf Grundlage früherer Daten darüber geführt, wie sich die lokale Uhr von der/den Netzwerkuhr(en) unterscheidet. Ich vermute, dass das betreffende Motherboard nie eine gute Uhr hatte und die Uhr schließlich so schlecht wurde, dass die „Skew-Datei“ mit ihrer starken Abweichung einfach nicht mehr mithalten konnte.

verwandte Informationen