Сервер Debian Stable (5.0.3) работает ntpdи подключен к Интернету. Тем не менее, системные часы около 5 минут неправильно.
$ /etc/init.d/ntp status
NTP server is running..
Соответствующие части (я думаю) о /etc/ntp.conf:
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.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org
Я знаю, что NTP не обязательно приводит часы вовремя. Тем не менее, сколько часов или дней вам нужно ждать, чтобы разумно ожидать, что NTP выполнил свою работу и синхронизировал часы?
Я пропускаю какой-то другой файл конфигурации или опцию, или просто что-то не так? Является ли ntp (вместо, например, ntpdate ) подходящим инструментом для этого? Есть ли какой-нибудь быстрый способ проверить правильность конфигурации и правильность времени выбранных серверов NTP?
Редактировать : вывод ntpq -p:
remote refid st t when poll reach delay offset jitter
==============================================================================
ns1.nexellent.n .INIT. 16 u - 1024 0 0.000 0.000 0.000
dnscache-madrid .INIT. 16 u - 1024 0 0.000 0.000 0.000
sinister.wzw.tu .INIT. 16 u - 1024 0 0.000 0.000 0.000
dnscache-frankf .INIT. 16 u - 1024 0 0.000 0.000 0.000
Редактировать 2 : Оказывается, ntpdate -u 0.europe.pool.ntp.orgкоманда ( предложенная Brent ) возвращает
17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found
... хотя на других машинах эта команда работает нормально. Итак, мы рассмотрим настройки сети / брандмауэра для этого конкретного сервера (который находится в другой сети, доступ к которой осуществляется через VPN).
Решение : виновником был не локальный брандмауэр на нашем сервере, а настройки брандмауэра где-то в соседней сети. Поэтому мы попросили провайдера хостинга серверов разрешить NTP для наших машин, и теперь он работает нормально. Например, ntpq -pтеперь возвращает:
remote refid st t when poll reach delay offset jitter
==============================================================================
ns1.eunet.fi 192.36.144.23 2 u 10 64 1 1.043 0.258 0.001
ns2.eunet.fi 62.142.10.44 2 u 9 64 1 0.671 0.135 0.001
ns3.eunet.fi 62.142.10.44 2 u 8 64 1 0.750 0.277 0.001
(Мы также переключились на серверы eunet.fi, рекомендованные хостинговой компанией, но это не относится к делу.) Команды в ответе Брента были полезны, потому что они помогли мне понять, что проблема заключалась в сетевом доступе к серверам NTP, а не в конфигурации NTP. сам. Спасибо всем!
Ответы:
Остановите ntpd, запустите
ntpdate -u 0.europe.pool.ntp.org3 раза, запустите ntpd, проверьтеntpq -p, задержка, смещение и джиттер должны быть ненулевыми.источник
ntpdateработает и синхронизирует мои часы, но все значения остаются0после перезагрузкиntp. Почему это работает, если я делаю это вручную, но не используюntpd? Я на Debian, кстати.Если бы мне пришлось догадываться, почему и при условии, что у вас есть сетевое подключение и вы можете без проблем видеть ваш NTP-хост, то это могло быть то, что вы перешли к большому значению. Если разница во времени больше, чем X (извините, я не помню, что это за X), тогда будет напечатано предупреждение, и время не будет синхронизировано. Вы можете проверить ваши сообщения системного журнала для случаев этого.
Если это так, остановите NTP, запустите ntpdate host и перезапустите NTPD, это вызовет синхронизацию времени, затем начните поддерживать синхронизацию в дальнейшем, если вы продолжите дрейфовать настолько, что у вас может возникнуть аппаратная проблема.
источник
Столбцы «досягаемость», равные 0, указывают на то, что он не мог общаться с серверами, - поэтому он постепенно сдвигает биты, чтобы показать, как прошли последние 8 попыток (таким образом, 377 - это хорошо, 0 - это плохо).
источник