i salti temporali del sistema linux

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 casuale e torna alla normalità nel messaggio successivo, come il seguente:

22 febbraio 2018 09:09:30 ...
22 febbraio 2018 09:09:32 ...
13 gennaio 2610 15:37:42 ...
22 febbraio 2018 09:09:33 ...
22 febbraio 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 gli 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?

— Zhaohui Yang
fonte

Puoi mostrare l'output di un hwclockloop? Qualcosa come:while true; do hwclock; sleep 5; done

— shodanshok,

ogni server ha il servizio ntp in esecuzione: come client o come server? tramite systemd o al di fuori di systemd tramite "vecchio" servizio ntp? per me questo sembra un problema di fornitura di ntp time. abbiamo riscontrato questo problema: abbiamo scritto i file di log prima che il nostro tempo fosse sincronizzato (prima di avere la connettività di rete, con conseguenti salti di timestamp) Tempo di sistema raggiunto raggiunto Sincronizzato.

— Dennis Nolte,

sembra che un po 'di recupero della data sia eseguito come cron e che non abbia un buon tempo di controllo. Trovalo, rimuovilo e sostituiscilo con ntpd che non risponde a grandi derive.

— danblack,

Abbiamo nuovi risultati e abbiamo scoperto che il problema può essere ridotto ai messaggi CRON ritardati in syslog. Quindi ho pubblicato un'altra domanda . Per favore dai un'occhiata qui.

— Zhaohui Yang,

Forse questo è il tuo errore: salti di tempo inspiegabili in CRON è stato corretto in rsyslog - 7.4.4-1ubuntu2.7 .

— Stone,

Risposte:

Questo script ti dirà quando si verifica una deriva temporale e la differenza nell'albero del processo, e questo dovrebbe aiutare a identificarlo se è causato da un processo che cambia l'ora del sistema. Verrà stampato sul terminale e accederà a timedrift.log all'interno della directory di lavoro corrente.

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

Ringraziamo la sceneggiatura originale nell'inspiegabile salto di tempo nel bug CRON che Stone ha menzionato come commento.

Puoi anche commentare come se stessi usando rsyslog e, in caso affermativo, quale versione? Lo vedi al di fuori del regno di rsyslog (es. Registri apache, ecc.). Questo bug sembra simmlar e sarebbe bello confermarlo o escluderlo in entrambi i modi.

— Citizen Kepler
fonte

In realtà questo è un duplicato del commento di @Stone. Metti in chiaro a tutti che questa ha una risposta.

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

— Zhaohui Yang
fonte