Il tempo del sistema Linux salta temporaneamente

Ho visto uno strano orario di sistema cambiare comportamento in alcuni server (hardware): in /var/logs/syslog, l'ora della data che precede ogni messaggio di registro a volte cambia in uno casuale e torna alla normalità nel messaggio successivo, come il seguente:

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

Come nell'esempio, l'improvviso cambio di data e ora può arrivare a centinaia di anni.

Posso confermare che i messaggi di registro con strani timestamp non provengono da alcun processo specifico, ma possono capitare casualmente per ognuno.

E la durata tra 2 cambi di tempo anormali varia da pochi minuti a qualche ora (tuttavia, sospetto che i cambiamenti di tempo anormali potrebbero verificarsi più frequentemente, ma molti di essi non vengono rivelati nel syslog, poiché non scrive registri ogni secondo).

Inoltre, poiché accade su più di un server, presumo che non sia un problema hardware.

Maggiori informazioni sui server: sono un'installazione openstack con un controller e alcuni nodi di calcolo. Ogni server ha il servizio ntp in esecuzione. Il controller è configurato per richiedere tempo dal proprio clock hardware e i server dei nodi di calcolo sincronizzano il tempo dal controller. Si noti che ogni server ha variazioni orarie anomale al proprio ritmo - sembra che "l'ora sbagliata" non sia sincronizzata dal controller tramite ntp.

Sospettavo che i sistemi guest (macchine virtuali) sui nodi di calcolo potessero influenzare il tempo del loro sistema host. Ma questo non può spiegare perché il controller abbia lo stesso problema mentre non esegue alcuna macchina virtuale.

Ho bisogno di un metodo per rilevare: chi ha cambiato l'ora di sistema e come succede?

Gli aspetti rilevanti sono le versioni del kernel e queste righe dall'inizio del processo di avvio:

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

YMMV e potresti non utilizzare TSC o PIT

AFAIK questo è un bug che è causato dal fatto che l'orologio di almeno una delle tue CPU non è sincronizzato, nel tuo caso probabilmente funziona troppo velocemente.

Dovrebbe essere facile confermare eseguendo questo:

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

che verrà eseguito datesu ogni CPU (supponendo di avere fino a 8 core / thread). Se la mia ipotesi è corretta, allora una delle tue CPU avrà costantemente il momento sbagliato.

In tal caso, dovresti prima provare ad aggiornare il kernel e se ciò non funziona, giocherellare con il parametro di avvio clocksource (supponendo che sia 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

Vedi anche l'output di questo:

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

Sembra che l'orologio hardware sul server del controller non sia una risorsa stabile di informazioni sull'ora. È necessario configurare il controller per sincronizzare il tipo con un orologio atomico più affidabile.

Questo è il comando che puoi usare per aggiornare il tuo orologio hardware: hwclock -s

Guarda anche:

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

copiato da: messaggi CRON ritardati per molto tempo arbitrario in syslog :

In breve, c'è un bug nella versione di rsyslog che sto usando, che ritarderà il messaggio syslog che ha ricevuto per un periodo di tempo arbitrario. La segnalazione di bug è qui. E l'aggiornamento di rsyslog ha risolto il problema. Non è colpa di CRON.

È necessario utilizzare un server NTP esterno sincronizzato con una sorgente di strato 1 o 2 per evitare tali anomalie. Gli orologi hardware non sono affidabili.