Возможные причины внезапной смерти NTPD и решения

9

В веб-приложении, использующем s3 для хранения физических документов, у нас возникают проблемы с непрерывным отмиранием NTP. Кажется, это происходит примерно один или два раза в день. Когда это происходит, предоставляется очень мало информации, за исключением того, что файл PID существует, но служба не работает, когда я проверяю состояние.

Кто-нибудь может предложить вероятные причины смерти NTPD? Я предполагаю, что, возможно, дрейф часов заставляет их умирать, но я не уверен, что также вызвало бы это. Недостаточно памяти и свободного места на диске.

В прошлый раз, когда сервис умер, это был вывод:

Sep  6 06:15:25 vm02 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="988" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Sep  6 06:17:06 vm02 ntpd[10803]: 0.0.0.0 0618 08 no_sys_peer
Sep  6 08:01:10 vm02 ntpd[10803]: 0.0.0.0 0617 07 panic_stop -28101 s; set clock manually within 1000 s.

— user275940
источник

Какая ОС и версия? Работает ли шкура? Сколько ntp-серверов настроено? Какие опции ntpd активны?

— Нильс

Вы можете попробовать удалить файл ntp.drift, его значение может быть слишком высоким и привести к

— перекосу

6

Я бы сказал, что нет 1-минутного метода, чтобы найти точную причину.

У нас были подобные проблемы раньше в нашей среде ESXi. Короче говоря, мы обнаружили, что часы хоста ESXi сильно сдвинулись, а гостевые виртуальные машины синхронизировали время как с хоста ESXi, так и с вышестоящего NTP-сервера. Это вызвало путаницу NTPd на виртуальных машинах, поэтому они часто умирали.

Мы также обнаружили, что в некоторых редких случаях случайная потеря пакетов также приводила к выходу NTPd, поскольку время обхода между вашим сервером и вышестоящим сервером NTPd используется для расчета времени дрейфа.

В двух вышеупомянутых случаях, если NTPd видит значительный временной сдвиг, например, более 1000 с, он по умолчанию завершает работу. Опция -g немного поможет.

   -g      Normally,  ntpd  exits  with  a  message to the system log if the offset exceeds the panic threshold,
           which is 1000 s by default. This option allows the time to be set to any value  without  restriction;
           however,  this  can  happen only once. If the threshold is exceeded after that, ntpd will exit with a
           message to the system log. This option can be used with the -q and -x options. See the tinker command
           for other options.

Вы можете взглянуть на системный журнал , в котором должно быть несколько слов, которые могут дать вам подсказку. Вы также можете отслеживать вывод «ntpq -p», чтобы иметь общее представление о том, как развивается смещение.

— Энцо Ван
источник

Когда вы запускаете ntpd на виртуальных машинах, вы также не должны синхронизировать время с хостом и не должны включать локальные часы в качестве ссылки.

— Пол Гир

3

Сообщение журнала ясно указывает на то, что дрейф часов является причиной выхода. Возможные решения:

Запустите ntpd с флагом -g; однако, это не исправит основную причину, которая является перекосом часов.
Запустите ntpdate перед запуском ntpd; вероятно, то же самое.
Добавьте больше источников времени; NTP нуждается в 4-6 источниках для поддержания хорошей точности. Простой способ сделать это - включить в вашу конфигурацию повторные ссылки на [0-3] .YOURREGION.pool.ntp.org, например
```
server 0.au.pool.ntp.org iburst
server 1.au.pool.ntp.org iburst
server 2.au.pool.ntp.org iburst
server 3.au.pool.ntp.org iburst

server 0.au.pool.ntp.org iburst
server 1.au.pool.ntp.org iburst
server 2.au.pool.ntp.org iburst
server 3.au.pool.ntp.org iburst
```

— Пол Гир
источник

1

Другой вариант, который вы можете попробовать, это хрон. В нашем тестировании он работает более стабильно, чем ntpd, и лучше справляется с перекосом времени в виртуальных средах.

http://chrony.tuxfamily.org/

— Jokajak
источник