El tiempo del sistema Linux salta temporalmente

Vi un comportamiento extraño del sistema de cambio de hora en algunos servidores (hardware): en /var/logs/syslog, la fecha y hora que precede a cada mensaje de registro a veces cambia a uno aleatorio y vuelve a la normalidad en el siguiente mensaje, como el siguiente:

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

Como en el ejemplo, el cambio repentino de fecha y hora puede estar a cientos de años de distancia.

Puedo confirmar que los mensajes de registro que tienen marcas de tiempo extrañas no provienen de ningún proceso específico, solo pueden suceder al azar para cada uno.

Y la duración entre 2 cambios de tiempo anormales varía entre unos minutos y unas pocas horas (sin embargo, sospecho que los cambios de tiempo anormales podrían ocurrir con mayor frecuencia, pero muchos de ellos no se revelan en el registro del sistema, ya que no está escribiendo registros cada segundo).

Además, dado que ocurre en más de un servidor, supongo que no es un problema de hardware.

Más información sobre los servidores: son una instalación de taladro abierto con un controlador y algunos nodos de cómputo. Cada servidor tiene un servicio ntp ejecutándose. El controlador está configurado para tomar tiempo de su propio reloj de hardware, y los servidores de nodo de cómputo sincronizan el tiempo del controlador. Tenga en cuenta que cada servidor tiene cambios de hora anormales a su propio ritmo; parece que el "momento incorrecto" no está sincronizado desde el controlador a través de ntp.

Sospechaba que los sistemas invitados (máquinas virtuales) en los nodos informáticos podrían afectar la hora de su sistema host. Pero esto no puede explicar por qué el controlador tiene el mismo problema mientras no ejecuta ninguna máquina virtual.

Necesito un método para detectar: ​​¿quién cambió la hora del sistema y cómo sucede?

Los aspectos relevantes son las versiones del kernel y estas líneas desde el principio del proceso de arranque:

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

YMMV y es posible que no esté utilizando TSC o PIT

AFAIK este es un error causado por el reloj de al menos una de sus CPU fuera de sincronización, en su caso, probablemente corriendo demasiado rápido.

Debería ser fácil de confirmar ejecutando esto:

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

que se ejecutará dateen cada CPU (suponiendo que tenga hasta 8 núcleos / subprocesos). Si mi suposición es correcta, una de sus CPU siempre tendrá el momento equivocado.

Si ese es el caso, primero debe intentar actualizar el kernel y si eso no funciona, juegue con el parámetro de inicio de clocksource (suponiendo que sea 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

Vea también el resultado de esto:

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

Parece que el reloj de hardware en su servidor controlador no es un recurso estable de información sobre la hora. Debe configurar su controlador para sincronizar su tipo con un reloj atómico más confiable.

Este es el comando que puede usar para actualizar su reloj de hardware: hwclock -s

Ver también:

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

copiado de: los mensajes CRON se retrasan por mucho tiempo arbitrario en syslog :

En resumen, hay un error en la versión de rsyslog que estoy usando, lo que retrasará el mensaje de syslog que recibió durante un período de tiempo arbitrario. Informe de error está aquí. Y actualizar rsyslog resolvió el problema. No es culpa de CRON.

Debe usar un servidor NTP externo sincronizado con una fuente de estrato 1 o 2 para evitar tales anomalías. Los relojes de hardware no son confiables.