le temps du système linux saute temporellement

J'ai vu un étrange comportement de modification de l'heure du système sur certains serveurs (matériels): dans / var / logs / syslog, l'heure de la date précédant chaque message de journal change parfois de manière aléatoire et revient à la normale dans le message suivant, comme suit:

22 févr.2018 09:09:30 ...
22 févr.2018 09:09:32 ...
13 janv.2610 15:37:42 ...
22 févr.2018 09:09:33 ...
22 févr.2018 09:09:34 ...

Comme dans l'exemple, le changement soudain de date et d'heure peut atteindre des centaines d'années.

Je peux confirmer que les messages de journal ayant les horodatages étranges ne proviennent pas d'un processus spécifique - cela peut simplement arriver au hasard pour chacun.

Et la durée entre 2 changements d'heure anormaux varie entre quelques minutes et quelques heures (cependant, je soupçonne que les changements d'heure anormaux pourraient se produire plus fréquemment mais beaucoup d'entre eux ne sont pas révélés dans le syslog, car il n'écrit pas les journaux toutes les secondes).

De plus, comme cela se produit sur plusieurs serveurs, je suppose que ce n'est pas un problème matériel.

Plus d'informations sur les serveurs: il s'agit d'une installation openstack avec un contrôleur et quelques nœuds de calcul. Chaque serveur a un service ntp en cours d'exécution. Le contrôleur est configuré pour prendre du temps à partir de sa propre horloge matérielle, et les serveurs de nœuds de calcul synchronisent l'heure du contrôleur. Notez que chaque serveur a des changements d'heure anormaux à son propre rythme - il semble que le "mauvais moment" ne soit pas synchronisé depuis le contrôleur via ntp.

Je soupçonnais que les systèmes invités (machines virtuelles) sur les nœuds de calcul pourraient affecter l'heure de leur système hôte. Mais cela ne peut pas expliquer pourquoi le contrôleur a le même problème lorsqu'il n'exécute aucune machine virtuelle.

J'ai besoin d'une méthode pour détecter: qui a changé l'heure du système et comment cela se produit-il?

Ce script vous indiquera quand une dérive temporelle se produit et la différence dans l'arborescence des processus, et cela devrait aider à l'identifier si elle est causée par un processus modifiant l'heure du système. Il s'imprime sur le terminal et se connecte à timedrift.log dans le répertoire de travail actuel.

#!/bin/bash

oldTime="$(date +%s)"
oldPsOutput="$(ps faux)"
while true; do
  sleep 1;
  currentTime="$(date +%s)"
  oldTimeplusfive="$((($oldTime+5)))"
  currentPsOutput="$(ps faux)"
  if [[ "$currentTime" -lt "$oldTime" ||  "$currentTime" -gt "$oldTimeplusfive"  ]]
  then
    (
        echo -e '\n\n======================='
        echo "currentTime=$currentTime oldTime=$oldTime oldTimeplusfive=$oldTimeplusfive"
        echo '-----------------------'
        echo "$oldPsOutput"
        echo '::::::::::::::::::::::::::'
        echo "$currentPsOutput"
    ) | tee -a timedrift.log
  fi
  oldPsOutput=$currentPsOutput
  oldTime=$currentTime
done

Crédits au script original dans les sauts de temps inexplicables dans le bug CRON que Stone a mentionné comme commentaire.

Pouvez-vous également commenter comme si vous utilisez rsyslog et si oui quelle version? Le voyez-vous en dehors du domaine de rsyslog (c.-à-d. Journaux apache, etc.). Ce bogue semble similaire, et il serait bon de le confirmer ou de l'exclure de toute façon.

En fait, c'est un double du commentaire de @Stone. Faites juste comprendre à tout le monde que cela a une réponse.

En bref, il y a un bug dans la version de rsyslog que j'utilise. Ce qui retardera le message syslog qu'il a reçu pendant une durée arbitraire. Le rapport de bogue est ici. Et la mise à niveau de rsyslog a résolu le problème. Ce n'est pas la faute du noyau ou du CRON.