
В нашем производственном ящике я столкнулся с проблемой ntpd. Я включаю функцию NTP для нашего производственного ящика и наблюдаю одну проблему.
Запускаем демон ntpd в процессе инициализации нашего ящика. В это время интернет-подключения нет. Ниже мой небольшой ntp.conf
файл
driftfile /etc/ntp.drift
logconfig =syncstatus
server pool.ntp.org iburst
Наш ящик получает подключение к интернету немного поздно, как только интерфейс появляется. В этот раз я вижу, что ntpd не синхронизирует часы. Когда я это делаю ntpq -c as
, я получаю no association id's found
. Я ждал почти 30 минут, но все равно получилno association id's found
Мне нужно перезапустить ntpd. После перезапуска ntpd синхронизирует часы и все работает нормально. Но если я снова перезагружу свой ящик, то проблема повторится. Мне снова нужно перезапустить ntpd, как только ящик загрузится и интернет будет доступен.
Сталкивался ли кто-нибудь с подобной проблемой?
Стоит ли отложить запуск ntpd до появления временного интерфейса?
Обновлять
Я провел еще несколько экспериментов и заменил server pool.ntp.org iburst
на pool pool.ntp.org iburst
и с этим изменением ntpd синхронизирует часы автоматически. Мне не пришлось перезапускать ntpd. Так что здесь у меня возникает еще один вопрос.
Что произошло, когда я заменил server
на pool
?
Всегда ли мне следует использовать pool
ключевое слово вместо server
?
Когда следует использовать pool
и когда следует использовать server
?
Я провел небольшое исследование и обнаружил, что
pool is the same as server, except it resolves one name into several addresses and uses them all
если они делают одно и то же, то почему server pool.ntp.org iburst
у меня это не сработало, а у pool pool.ntp.org iburst
меня сработало?
Обновлять
Как и предполагалось, я использовал pool
вместо , server
но мои часы все еще не могут синхронизироваться при загрузке. Раньше no association id's found
приходил, но после использования пула он отображает список.
GW:/admin# ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
===================================================================== =========
time.google.com .POOL. 16 p - 64 0 0.000 +0.000 0.002
GW:/admin# ntpq -np
remote refid st t when poll reach delay offset jitter
time.google.com .POOL. 16 p - 64 0 0.000 +0.000 0.002
GW:/admin# ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 34173 8811 yes none none reject mobilize 1
GW:/admin# ntpq -c "rv 34173"
associd=34173 status=8811 conf, bcast, sel_reject, 1 event, mobilize,
srcadr=0.0.0.0, srcport=0, srchost="time.google.com", dstadr=0.0.0.0,
dstport=0, leap=11, stratum=16, precision=-19, rootdelay=0.000,
rootdisp=0.000, refid=POOL, reftime=(no time), rec=(no time), reach=000,
unreach=0, hmode=3, pmode=0, hpoll=6, ppoll=10, headway=0,
flash=1400 peer_dist, peer_unreach, keyid=0, offset=+0.000, delay=0.000,
dispersion=16000.000, jitter=0.002,
filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00,
filtoffset= +0.00 +0.00 +0.00 +0.00 +0.00 +0.00 +0.00 +0.00,
filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
Я вижу статус вспышки как 1400
. Что означает 1400
Я не смог найти статус вспышки 1400
в документации ntp.
Обновлять
Он начал работать. Я заменил его iburst
на minpoll 3 maxpoll 4
и после этого он работает при перезагрузке. Я использовал пул таким образом pool pool.ntp.org minpoll 3 maxpoll 4
. Я не уверен, что это изменение изменило.
Я также читал, что следует избегать использования minpoll и maxpoll.
Too frequent for a sustained period and public NTP services may block you. ntpd is already good at dynamically selecting the pool interval.
В любом случае спасибо вам всем за помощь.
решение1
Когда вы указываете сервер для ntpd, при запуске он преобразует имя хоста в IP-адрес и пытается использовать IP-адрес для синхронизации времени. Если это имя хоста не преобразуется, он удаляет его. Даже если он преобразует его, он не запоминает имя хоста, только IP-адрес.
Если сервер в вашей server
линии был локальным хостом с фиксированным IP-адресом (а не динамическим пулом), вы можете заменить имя хоста реальным IP-адресом, и он не должен быть удален, даже если сеть не была запущена при запуске.
Если вместо этого вы укажете пул для ntpd, он сохранит имя хоста (и пометит его тегом .POOL.
). Периодически (в том числе при запуске) он будет разрешать это имя хоста в DNS и добавлять все полученные IP-адреса в качестве отдельных записей, а также удалять некоторые наименее благоприятные.
Вы можете увидеть часть этого с помощью команды ntpq -np
или эквивалентноntpq -n -c peers
Обратите внимание, что существуют также проблемы с синхронизацией и проблемы с версией ntpd со всем этим. Эта точная проблема была зарегистрирована как ошибка в ntpd, и было несколько вариантов исправления. Некоторые версии ntpd откладывают разрешение имени хоста, если оно не удается, но в конечном итоге он все равно может отказаться; поэтому, если вы проводите тестирование, кратковременно отключая сеть и подключая ее снова, проблема может не возникнуть. Кроме того, ntp использует алгоритм опроса, который экспоненциально увеличивает время опроса хоста как для доступных, так и для недоступных хостов (в зависимости от стабильности ваших часов и полезности хоста в качестве временной синхронизации) с верхним пределом в 1024 секунды (32 минуты), поэтому, если доступность сети изменяется, может потребоваться столько времени, чтобы он заметил это. (Время опроса и интервалы указаны в ntpq -np
)
Кроме того, некоторые скрипты запуска загрузки используют ntpdate или аналогичные инструменты для установки системных часов на сервер из ntp.conf, чтобы часы были частично синхронизированы до запуска ntpd. Это одноразовая попытка, и если она не удалась, ntpd может запуститься с сильно неправильными часами. Если они только немного неправильны, ntp исправит это, но если они сильно неправильны, ntpd может отказаться синхронизировать часы, а в некоторых случаях и версиях ntpd может аварийно завершить работу. Некоторые версии ntpd имеют свои собственные опции большого шага часов для одноразовых часов.