Mögliche Ursachen für unerwartetes Absterben von NTPD und Lösungen

In einer Webanwendung, die s3 für die physische Dokumentenspeicherung verwendet, treten Probleme mit NTP auf, die ständig aussterben. Dies scheint ungefähr ein- oder zweimal am Tag zu geschehen. In diesem Fall werden nur sehr wenige Informationen bereitgestellt, außer dass die PID-Datei vorhanden ist, der Dienst jedoch nicht mehr verfügbar ist, wenn ich den Status überprüfe.

Kann jemand mögliche Ursachen für das Sterben von NTPD vorschlagen? Ich gehe davon aus, dass die Zeitverschiebung möglicherweise dazu führt, dass es stirbt, aber ich bin mir nicht sicher, was das auch verursachen würde. Es gibt mehr als genug Speicher und verfügbaren Speicherplatz.

Das letzte Mal, als der Dienst starb, war dies die Ausgabe:

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.

Ich würde sagen, es gibt keine 1-Minuten-Methode, um den genauen Grund zu finden.

Wir hatten zuvor ähnliche Probleme in unserer ESXi-Umgebung. Um die Geschichte kurz zu machen, wir haben festgestellt, dass die Uhr des ESXi-Hosts stark verschoben ist und Gast-VMs die Zeit sowohl vom ESXi-Host als auch vom Upstream-NTP-Server synchronisieren. Dies führte dazu, dass NTPd auf VMs verwirrt war und daher ziemlich oft starb.

In einigen seltenen Fällen haben wir auch festgestellt, dass der zufällige Paketverlust auch dazu führte, dass NTPd beendet wurde, da die Roundtrip-Zeit zwischen Ihrem Server und dem Upstream-NTPd-Server zur Berechnung der Driftzeit verwendet wird.

In den beiden oben genannten Fällen wird NTPd standardmäßig beendet, wenn eine massive Zeitverschiebung auftritt, z. B. mehr als 1000 Sekunden. Die Option -g hilft ein bisschen.

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

Sie können sich das Systemprotokoll ansehen , das einige Wörter enthalten sollte, die Ihnen möglicherweise einen Hinweis geben. Sie können auch die Ausgabe von "ntpq -p" überwachen , um eine ungefähre Vorstellung davon zu erhalten, wie sich der Offset entwickelt.

Die Protokollmeldung zeigt deutlich an, dass die Taktdrift der Grund für den Ausgang ist. Mögliche Lösungen:

• Starten Sie ntpd mit dem Flag -g. Dies behebt jedoch nicht die Grundursache, nämlich den Zeitversatz.
• Führen Sie ntpdate aus, bevor Sie ntpd starten. wahrscheinlich die gleiche Einschränkung.

• Fügen Sie weitere Zeitquellen hinzu. NTP benötigt 4-6 Quellen, um eine gute Genauigkeit aufrechtzuerhalten. Eine einfache Möglichkeit, dies zu tun, besteht darin, wiederholte Verweise auf [0-3] .YOURREGION.pool.ntp.org in Ihre Konfiguration aufzunehmen, z

  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
  

Eine andere Option, die Sie ausprobieren können, ist chrony. In unseren Tests ist es stabiler als ntpd und verarbeitet Zeitverzerrungen in virtuellen Umgebungen besser.

http://chrony.tuxfamily.org/