Le temps du système Linux saute temporellement

J'ai vu un étrange comportement de changement d'heure 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 en aléatoire et revient à la normale dans le message suivant, comme suit:

Feb 22 2018 09:09:30 ...  
Feb 22 2018 09:09:32 ...  
Jan 13 2610 15:37:42 ...  
Feb 22 2018 09:09:33 ...  
Feb 22 2018 09:09:34 ...  

Comme dans l'exemple, le changement soudain de date et d'heure peut aller jusqu'à 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?

Les aspects pertinents sont les versions du noyau et ces lignes depuis le début du processus de démarrage:

kernel: Fast TSC calibration using PIT
...
kernel: Calibrating delay loop (skipped), value calculated using timer frequency..
...
kernel: Switching to clocksource tsc

YMMV et vous n'utilisez peut-être pas TSC ou PIT

AFAIK c'est un bug qui est causé par l'horloge d'au moins un de vos processeurs qui n'est pas synchronisé, dans votre cas probablement en cours d'exécution trop rapide.

Il devrait être facile de confirmer en exécutant ceci:

for cpu in {0..8} ; do taskset -c $cpu date ; done

qui s'exécutera datesur chaque processeur (en supposant que vous ayez jusqu'à 8 cœurs / threads). Si ma supposition est correcte, l'un de vos processeurs aura toujours le mauvais moment.

Si c'est le cas, vous devriez d'abord essayer de mettre à niveau le noyau et si cela ne fonctionne pas, jouer avec le paramètre de démarrage clocksource (en supposant que ce soit le cas x86-64):

clocksource=    Override the default clocksource
                Format: <string>
                Override the default clocksource and use the clocksource
                with the name specified.
                Some clocksource names to choose from, depending on
                the platform:
                [all] jiffies (this is the base, fallback clocksource)
                [ACPI] acpi_pm
                ...
                [X86-64] hpet,tsc

Voir aussi la sortie de ceci:

cat /sys/devices/system/clocksource/clocksource*/available_clocksource

Il semble que l'horloge matérielle de votre serveur contrôleur ne soit pas une ressource stable d'informations sur l'heure. Vous devez configurer votre contrôleur pour synchroniser son type avec une horloge atomique plus fiable.

Voici la commande que vous pouvez utiliser pour mettre à jour votre horloge matérielle: hwclock -s

Voir également:

   -s, --hctosys
          Set the System Time from the Hardware Clock.

          Also set the kernel's timezone value to the local timezone as indicated by the TZ environment variable and/or /usr/share/zoneinfo, as tzset(3) would interpret them.  The obsolete tz_dsttime field of the kernel's time‐
          zone value is set to DST_NONE.  (For details on what this field used to mean, see settimeofday(2).)

          This is a good option to use in one of the system startup scripts.

   -w, --systohc
          Set the Hardware Clock to the current System Time.

copié depuis: les messages CRON sont retardés pendant une durée arbitraire dans syslog :

En bref, il y a un bogue dans la version de rsyslog que j'utilise, 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 de CRON.

Vous devez utiliser un serveur NTP externe synchronisé avec une source de couche 1 ou 2 pour éviter de telles anomalies. Les horloges matérielles ne sont pas fiables.