Prawdopodobne przyczyny nieoczekiwanego umierania NTPD i rozwiązania

W aplikacji internetowej używającej s3 do fizycznego przechowywania dokumentów mamy problemy z ciągłym umieraniem NTP. Wydaje się, że dzieje się to mniej więcej raz lub dwa razy dziennie. Gdy tak się dzieje, jest bardzo mało informacji, poza tym, że plik PID istnieje, ale usługa jest martwa, gdy sprawdzam status.

Czy ktoś może zasugerować prawdopodobne przyczyny śmierci NTPD? Zakładam, że może dryf zegara powoduje jego śmierć, ale nie jestem pewien, co by to spowodowało. Jest więcej niż wystarczająca ilość pamięci i dostępne miejsce na dysku.

Ostatnim razem, gdy usługa umarła, oto wynik:

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.

Powiedziałbym, że nie ma 1-minutowej metody na znalezienie dokładnego powodu.

W naszym środowisku ESXi mieliśmy podobne problemy. Krótko mówiąc, stwierdziliśmy, że zegar hosta ESXi bardzo płynął, a maszyny wirtualne gości synchronizowały czas zarówno z hosta ESXi, jak i z serwera NTP. To spowodowało zamieszanie NTPd na maszynach wirtualnych, dlatego dość często umarło.

W niektórych rzadkich przypadkach stwierdziliśmy również, że losowa utrata pakietów spowodowała także zamknięcie NTPd, ponieważ do obliczenia czasu dryfu wykorzystywany jest czas podróży w obie strony między serwerem a serwerem NTPd w górę.

W powyższych dwóch przypadkach, jeśli NTPd widzi ogromne przesunięcie czasu, na przykład o ponad 1000s, domyślnie kończy pracę. Opcja -g trochę pomoże.

   -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.

Możesz zajrzeć do dziennika systemu , który powinien zawierać kilka słów, które mogą dać ci podpowiedź. Możesz także monitorować wyjście „ntpq -p”, aby z grubsza zorientować się, jak rozwija się offset.

Komunikat dziennika wyraźnie wskazuje, że przesunięcie zegara jest przyczyną wyjścia. Możliwe rozwiązania:

• Uruchom ntpd z opcją -g; nie naprawi to jednak głównej przyczyny, jaką jest przekrzywienie zegara.
• Uruchom ntpdate przed uruchomieniem ntpd; prawdopodobnie to samo zastrzeżenie.

• Dodaj więcej źródeł czasu; NTP potrzebuje 4-6 źródeł, aby utrzymać dobrą dokładność. Prostym sposobem na to jest dołączenie w konfiguracji powtarzających się odniesień do [0-3] .YOURREGION.pool.ntp.org, np.

  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
  

Inną opcją, którą możesz wypróbować, jest chroniczna. W naszych testach działa bardziej stabilnie niż ntpd i lepiej radzi sobie z przesunięciem w czasie doświadczanym w środowiskach wirtualnych.

http://chrony.tuxfamily.org/