В веб-приложении, которое использует 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.
Я бы сказал, что не существует одноминутного метода, чтобы найти точную причину.
У нас раньше были похожие проблемы в нашей среде 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" иметь приблизительное представление о том, как развивается офсет.
Сообщение журнала четко указывает на то, что причиной выхода является дрейф часов. Возможные решения:
Добавить больше источников времени; 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
Другой вариант, который вы можете попробовать, - хрони. В нашем тестировании он работает более стабильно, чем ntpd, и лучше справляется с искажением времени в виртуальных средах.