Сервер 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 выполнил свою работу и синхронизировал часы?
Мне не хватает другого файла конфигурации или опции, или я просто делаю что-то не так? Является нтп (вместо, например, 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
команда (предложено Брентом) возвращается
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.org
3 раза запускаем ntpd, проверяем на ntpq -p
, задержка, смещение и джиттер должны быть ненулевыми.
Значение 0 в столбцах «досягаемости» указывает на то, что он не смог связаться с серверами, поскольку биты постепенно сдвигаются, чтобы показать, как прошли последние 8 попыток (так что 377 - хорошо, 0 - плохо).
Если бы мне пришлось угадывать, почему, и предполагая, что у вас есть сетевое подключение и вы можете видеть свой NTP-хост без проблем, возможно, вы перешли на большое значение. Если разница во времени больше X (извините, я не помню, что такое X), будет напечатано предупреждение, а время не будет синхронизироваться. Вы можете проверить сообщения системного журнала на наличие таких случаев.
Если это так, остановите NTP, запустите хост ntpdate и перезапустите NTPD, это вызовет синхронизацию времени, а затем начнет поддерживать его синхронизацию в дальнейшем, если вы продолжите так сильно дрейфовать, у вас может быть проблема с оборудованием.