A hora do sistema Linux salta temporalmente

Question

Eu vi um estranho sistema alterar o comportamento em alguns servidores (hardware): em /var/logs/syslog , o tempo de data que precede cada mensagem de log às vezes muda para um aleatório e volta ao normal na próxima mensagem, como segue:

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 no exemplo, a mudança repentina de data pode estar a centenas de anos de distância.

Posso confirmar que as mensagens de log com os estranhos carimbos de hora não vêm de nenhum processo específico - isso pode acontecer aleatoriamente para todos.

E a duração entre 2 alterações de tempo anormais varia entre alguns minutos a algumas horas (no entanto, suspeito que as alterações de hora anormais podem acontecer com mais frequência, mas muitas delas não são reveladas no syslog, pois não grava todos os logs segundo).

Além disso, como isso acontece em mais de um servidor, presumo que não seja um problema de hardware.

Mais informações sobre os servidores: eles são uma instalação de openstack com um controlador e alguns nós de computação. Cada servidor tem o serviço ntp em execução. O controlador é configurado para levar tempo de seu próprio relógio de hardware, e os servidores de nós de computação sincronizam o tempo do controlador. Observe que cada servidor tem alterações de horário anormais em seu próprio ritmo - parece que a "hora errada" não é sincronizada do controlador pelo ntp.

Eu suspeitava que os sistemas convidados (máquinas virtuais) nos nós de computação pudessem afetar o tempo do sistema host. Mas isso não pode explicar por que o controlador tem o mesmo problema enquanto não está executando nenhuma máquina virtual.

Eu preciso de um método para detectar: quem mudou a hora do sistema e como isso acontece?

    

Answer 1

Os aspectos relevantes são as versões do kernel e essas linhas desde o início do processo de inicialização:

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

YMMV e você pode não estar usando TSC ou PIT

AFAIK, este é um bug causado pelo fato de que pelo menos uma de suas CPUs está fora de sincronia, no seu caso, provavelmente, sendo executado muito rápido.

Deve ser fácil confirmar isso executando:

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

que executará date em cada cpu (supondo que você tenha até 8 núcleos / threads). Se meu palpite estiver correto, uma de suas CPUs terá sempre a hora errada.

Se for esse o caso, você deve primeiro tentar atualizar o kernel e, se isso não funcionar, mexa no parâmetro de inicialização clocksource (supondo que seja 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

Veja também a saída disso:

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

    

Answer 2

Parece que o relógio de hardware no seu servidor de controlador não é um recurso estável de informações sobre o tempo. Você deve configurar seu controlador para sincronizar seu tipo com um relógio atômico mais confiável.

Este é o comando que você pode usar para atualizar o relógio do seu hardware: hwclock -s

Veja também:

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

    

Answer 3

copiado de: mensagens CRON sendo atrasado por muito tempo arbitrariamente no syslog :

In short, there is a bug in the version of rsyslog I'm using, which will delay syslog message it received for arbitrary length of time. Bug report is here. And upgrading rsyslog solved the problem. It is not CRON's fault.