o tempo do sistema linux salta temporalmente

Eu vi uma hora estranha do sistema alterando o comportamento em alguns servidores (hardware): em / var / logs / syslog, a data e hora anterior a cada mensagem de log às vezes muda para uma aleatória e volta ao normal na próxima mensagem, como a seguir:

22 de fevereiro de 2018 09:09:30 ...
22 de fevereiro de 2018 09:09:32 ...
13 de janeiro de 2610 15:37:42 ...
22 de fevereiro de 2018 09:09:33 ...
22 de fevereiro de 2018 09:09:34 ...

Como no exemplo, a mudança repentina de data e hora pode chegar a centenas de anos.

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

E a duração entre duas alterações anormais de tempo varia entre alguns minutos e algumas horas (no entanto, eu suspeito que as alterações anormais de tempo possam ocorrer com mais frequência, mas muitas delas não são reveladas no syslog, pois ele não está gravando logs a cada segundo).

Além disso, como 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 do openstack com um controlador e alguns nós de computação. Cada servidor tem o serviço NTP em execução. O controlador está configurado para levar tempo a partir de seu próprio relógio de hardware, e os servidores dos nós de computação sincronizam o tempo com o controlador. Observe que cada servidor tem alterações de horário anormais no seu próprio ritmo - parece que o "horário errado" não é sincronizado do controlador através do 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.

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

— Zhaohui Yang
fonte

Você pode mostrar a saída de um hwclockloop? Algo como:while true; do hwclock; sleep 5; done

— shodanshok

cada servidor tem o serviço ntp em execução: como cliente ou como servidor? via systemd ou fora do systemd via serviço ntp "antigo"? para mim, isso parece um problema de tempo de ntp. tivemos esse problema que escrevemos arquivos de log antes de nosso horário ser sincronizado (antes de ter conectividade de rede, resultando em saltos de carimbos de data / hora) systemd tem um destino em que você pode confiar no systemd [1]: o tempo foi alterado systemd [1]: Tempo atingido do sistema sincronizado.

— Dennis Nolte

parece que alguma busca de data está sendo executada como um cron e não tem uma verificação de tempo muito boa. Encontre-o, remova-o e substitua-o por ntpd, que não responde a grandes desvios de tempo.

— Danblack 18/08/19

Temos novas descobertas e descobrimos que o problema pode ser reduzido a mensagens CRON atrasadas no syslog. Então eu postei outra pergunta . Por favor, dê uma olhada lá.

— Zhaohui Yang

Talvez este seja o seu erro: O tempo inexplicável salta no CRON e foi corrigido no rsyslog - 7.4.4-1ubuntu2.7 .

— Pedra

Respostas:

Esse script informará quando ocorrerá um desvio de tempo e a diferença na árvore de processos, e isso ajudará a identificar isso se for causado por um processo que altera a hora do sistema. Ele será impresso no terminal, bem como entrará no timedrift.log dentro do diretório de trabalho atual.

#!/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

Os créditos ao script original no salto inexplicável no bug do CRON que Stone mencionou como comentário.

Você também pode comentar como se estivesse usando o rsyslog e, em caso afirmativo, qual versão? Você o vê fora do domínio do rsyslog (por exemplo, logs do apache, etc). Esse bug parece semelhante, e seria bom confirmá-lo ou descartá-lo de qualquer maneira.

— Citizen Kepler
fonte

Na verdade, isso é uma duplicata do comentário de @Stone. Apenas deixe claro para todos que isso tem uma resposta.

Em suma, há um erro na versão do rsyslog que estou usando. O que atrasará a mensagem syslog recebida por um período arbitrário. O relatório de bug está aqui. E a atualização do rsyslog resolveu o problema. Não é culpa do kernel ou do CRON.

— Zhaohui Yang
fonte