tempo do sistema linux saltos temporais

Question

Eu vi um sistema estranho mudar 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 o seguinte:

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

Este script informará quando ocorre um desvio de tempo e a diferença na árvore de processos, e isso deve ajudar a identificar se isso é causado por um processo que altera a hora do sistema. Ele será impresso no terminal, assim como será registrado 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

O crédito ao script original no Unexplainable time aumenta no bug 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ê vê isso fora do reino do rsyslog (ou seja, logs do apache, etc). Este bug parece simmlar, e seria bom confirmá-lo ou descartá-lo de qualquer forma.

    

Answer 2

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

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