☰

Каковы возможные причины неустойчивой синхронизации NTP?

tag-icon • tag-icon ubuntu ntpd ntp clock
Каковы возможные причины неустойчивой синхронизации NTP?

В системе Ubuntu 10.04 я заметил следующие странные события синхронизации NTP:

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

Где 91.189.94.4 europium.canonical.com и единственная строка сервера ntp.conf:

server ntp.ubuntu.com

Обновление в 2:36 кажется совершенно фальшивым, поскольку оно отменяется через 25 минут.

Каковы могут быть возможные причины этого?

Я могу придумать:

  • удаленный NTP-сервер просто выдает неправильное время
  • проблемы с сетью (может ли большая задержка привести к таким отклонениям?)
  • Ошибка, вызванная секундой координации (вместо этого должен был произойти сбой, верно?)

Если проблема возникла в первом варианте, как я могу от этого защититься?

Достаточно ли умен NTPD, чтобы обращаться к нескольким серверам NTP (когда serverдоступно несколько линий ntp.conf) и определять, слишком ли сильно отличаются друг от друга разные ответы?

решение1

Я видел записи syslog, подобные этой, на машине Slackware несколько лет назад. Я думаю, что купил машину, о которой идет речь, в 2002 году и использовал ее практически круглосуточно в течение многих лет: это был мой сервер SSH, SMTP и HTTP. Сбои NTP происходили медленно и постепенно увеличивались в частоте.

В первый раз я исправил это, заменив батарейку «CMOS RAM», которая представляла собой одну из батареек CR2032 размером с монету (четвертак США) на материнской плате.

Еще через год или два эксплуатации эта машина просто перестала точно показывать время, и мне приходилось регулярно перезапускать ее ntpd. Насколько я понимаю, она ntpdхранит "файл перекоса", основанный на прошлых данных о том, как локальные часы отличаются от сетевых часов. Я предполагал, что материнская плата никогда не имела хороших часов, и часы в конце концов стали настолько плохими, что "файл перекоса" просто не мог поспевать за ее диким разбросом.

Связанный контент