Я скомпилировал ntp для arm. Мой клиент NTP не обновляет время ни с одного сервера, на который я ссылался в сообщении «Почему ntpd не обновляет время на моем сервере? (7)» Но ничего не работает .. Вот результат ntpq -pn
[Tue May 15 13:18:26 root@Unknown:bin]$./ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
125.62.193.121 .INIT. 16 u - 16 0 0.000 0.000 0.000
Я узнал, что refid не должен быть ".INIT", а значения задержки, смещения и джиттера не должны быть 0
О просмотре логов для ntpd
[Tue May 15 13:19:08 root@Unknown:bin]$tail -f ntp.log
15 May 12:29:35 ntpd[18175]: proto: precision = 1000.000 usec
15 May 12:29:35 ntpd[18175]: ntp_io: estimated max descriptors: 1024, initial socket boundary:
15 May 12:29:35 ntpd[18175]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
15 May 12:29:35 ntpd[18175]: Listen normally on 1 lo 127.0.0.1 UDP 123
15 May 12:29:35 ntpd[18175]: Listen normally on 2 eth1 173.39.19.72 UDP 123
15 May 12:29:35 ntpd[18175]: peers refreshed
15 May 12:29:35 ntpd[18175]: Listening on routing socket on fd #19 for interface updates
Кстати, ntpupdate -u ntp.ubuntu.com работает, но ntpd не работает. Мой ntp.conf содержит только одну строку
server 91.189.94.4 minpoll 4 maxpoll 4
где выше IP для ntp.ubuntu.com.
[Fri May 18 15:12:26 root@Unknown:~]$ping pool.ntp.org
PING pool.ntp.org (202.71.140.36): 56 data bytes
64 bytes from 202.71.140.36: seq=0 ttl=53 time=40.000 ms
64 bytes from 202.71.140.36: seq=1 ttl=53 time=39.000 ms
64 bytes from 202.71.140.36: seq=2 ttl=53 time=39.000 ms
64 bytes from 202.71.140.36: seq=3 ttl=53 time=39.000 ms
Пинг работает, но сервер не обновляет время
Ваш ntpd считает, что удаленная система - это уровень 16 (это означает, что у нее наименее надежное время). Большинство клиентов ntp не синхронизируются с такой системой. Я очень рекомендую использовать pool.ntp.org как описано в их направлениях.
Их пример ntp.conf файл:
driftfile /var/lib/ntp/ntp.drift
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org
Кроме того, вы никогда не должны использовать IP-адреса в файле конфигурации, если ваша система не поддерживает разрешение DNS из-за каких-то сумасшедших требований.
Обновить:
Проект NTP Pool пытается сделать полуинтеллектуальное предположение о том, какой сервер времени он должен вам вернуть. Но обычно вы должны указывать страну, в которой должны находиться серверы, используя код страны в именах хостов. Для Индии это будет:
server 0.in.pool.ntp.org
server 1.in.pool.ntp.org
server 2.in.pool.ntp.org
server 3.in.pool.ntp.org
Тот же дрейф, регистрация и другие параметры все равно будут применяться.
Ваша система не получает ответы NTP от сервера, который вы указали, это то, что означает «INIT» в столбце «refid»: он все еще находится в состоянии INITialization - отправка пакетов для получения INITial чтения времени.
Ping может работать, но может случиться так, что брандмауэр блокирует пакеты NTP (123 / udp) между вашим компьютером и тем, с которым вы пытаетесь связаться. Или может случиться так, что в вашем файле ntp.conf есть строка «restrict», которая является чрезмерно запретительной, и поэтому даже если пакеты попадают туда и обратно, они игнорируются. См. Предыдущий вопрос о сбое сервера:
Проблема с синхронизацией серверного времени с ntpd
Один из способов проверить, есть ли проблема сетевого уровня с пакетами NTP, - запустить "ntpdate {server}" от имени пользователя root, чтобы посмотреть, установит ли это часы локально (NB: ntpd не может работать, когда вы пытаетесь это сделать).
Если «ntpdate» не работает, это означает, что что-то блокирует пакеты NTP. Если «ntpdate» работает, а «ntpd» нет (как текущая ситуация в вопросе), это означает, что что-то еще в вашей конфигурации нарушает работу.
Помните, что просто потому, что "ping" к другому хосту работает, не означает, что службы на этом удаленном хосте работают. Возможно, службы, к которым вы пытаетесь подключиться, защищены брандмауэром или демоны не работают на удаленном компьютере. Ping (и traceroute) существуют просто для отладки подключения на уровне IP: они ничего не делают для проверки доступности / доступности службы транспортного уровня (TCP, UDP).