Назад | Перейти на главную страницу

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 выполнил свою работу и синхронизировал часы?

Мне не хватает другого файла конфигурации или опции, или я просто делаю что-то не так? Является нтп (вместо, например, 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, это вызовет синхронизацию времени, а затем начнет поддерживать его синхронизацию в дальнейшем, если вы продолжите так сильно дрейфовать, у вас может быть проблема с оборудованием.