Causes probables de la mort inattendue de NTPD et solutions

Sur une application Web qui utilise s3 pour le stockage de documents physiques, nous rencontrons des problèmes avec la mort continue de NTP. Cela semble se produire environ une ou deux fois par jour. Il y a très peu d'informations fournies lorsque cela se produit, à part que le fichier PID existe, mais le service est mort lorsque je vérifie l'état.

Quelqu'un peut-il suggérer des causes probables de décès par NTPD? Je suppose que peut-être que la dérive de l'horloge la fait mourir, mais je ne suis pas sûr de ce qui pourrait provoquer cela non plus. Il y a plus qu'assez de mémoire et d'espace disque disponible.

La dernière fois que le service est mort, c'était la sortie:

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.

Je dirais qu'il n'y a pas de méthode d'une minute pour trouver la raison exacte.

Nous avions des problèmes similaires auparavant dans notre environnement ESXi. Pour faire court, nous avons constaté que l'horloge de l'hôte ESXi dérivait beaucoup et que les machines virtuelles invitées synchronisaient l'heure à la fois sur l'hôte ESXi et sur le serveur NTP en amont. Cela a provoqué la confusion de NTPd sur les VM et est donc mort assez souvent.

Nous avons également constaté que, dans de rares cas, la perte aléatoire de paquets a également provoqué la fermeture de NTPd car le temps d'aller-retour entre votre serveur et le serveur NTPd en amont est utilisé pour calculer le temps de dérive.

Dans les deux cas ci-dessus, si NTPd voit une dérive temporelle massive, par exemple plus de 1000, il se ferme par défaut. L'option -g vous aidera un peu.

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

Vous pouvez consulter le journal système , qui devrait contenir quelques mots qui peuvent vous donner un indice. Vous pouvez également surveiller la sortie "ntpq -p" pour avoir une idée approximative de l'évolution du décalage.

Le message du journal indique clairement que la dérive de l'horloge est la raison de la sortie. Solutions possibles:

• Démarrez ntpd avec le drapeau -g; cependant, cela ne résoudra pas la cause première, qui est le décalage d'horloge.
• Exécutez ntpdate avant de démarrer ntpd; probablement la même mise en garde.

• Ajoutez plus de sources de temps; NTP a besoin de 4 à 6 sources pour maintenir une bonne précision. Une façon simple de le faire est d'inclure des références répétées à [0-3] .YOURREGION.pool.ntp.org dans votre configuration, par exemple

  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
  

Chrony est une autre option que vous pouvez essayer. Dans nos tests, il fonctionne de manière plus stable que ntpd et gère mieux le décalage temporel connu dans les environnements virtuels.

http://chrony.tuxfamily.org/