NTP работает, системные часы еще не успели - что дает?

Сервер 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, задержка, смещение и джиттер должны быть ненулевыми.

Если бы мне пришлось догадываться, почему и при условии, что у вас есть сетевое подключение и вы можете без проблем видеть ваш NTP-хост, то это могло быть то, что вы перешли к большому значению. Если разница во времени больше, чем X (извините, я не помню, что это за X), тогда будет напечатано предупреждение, и время не будет синхронизировано. Вы можете проверить ваши сообщения системного журнала для случаев этого.

Если это так, остановите NTP, запустите ntpdate host и перезапустите NTPD, это вызовет синхронизацию времени, затем начните поддерживать синхронизацию в дальнейшем, если вы продолжите дрейфовать настолько, что у вас может возникнуть аппаратная проблема.

Столбцы «досягаемость», равные 0, указывают на то, что он не мог общаться с серверами, - поэтому он постепенно сдвигает биты, чтобы показать, как прошли последние 8 попыток (таким образом, 377 - это хорошо, 0 - это плохо).