Ймовірно, причини несподіваного вмирання НТРД і рішення

9

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

Чи може хтось запропонувати ймовірні причини вмирання НТРД? Я припускаю, що, можливо, переміщення годинників спричиняє його смерть, але я не впевнений, що може це спричинити. Тут є більш ніж достатньо пам’яті та доступного місця на диску.

Востаннє, коли служба померла, це було результатом:

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, його значення може бути занадто високим і викликає перекос

— Rqomey

6

Я б сказав, що немає жодної хвилини, щоб знайти точну причину.

У нас в середовищі ESXi були подібні проблеми. Якщо коротко сказати, ми виявили, що годинник хоста ESXi сильно переміщався, і гості віртуальних машин синхронізували час як з хостом ESXi, так і з вище NTP-сервера. Це викликало плутанину NTPd на VM, тому вмирали досить часто.

Ми також виявили, що в деяких рідкісних випадках випадкова втрата пакету також призвела до відмови від 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/

— Джокаджак
джерело