l'ora di dmesg e l'ora di sistema non sono corrette

Spero che qui ci sia qualcuno che possa aiutarmi con questo strano problema.

Penso di sapere perché sta accadendo ma non so come risolverlo. Forse è perché il tempo del BIOS non è impostato correttamente o qualcosa del genere. Ma non voglio cambiare il tempo del BIOS di circa 400+ server. (O cambia la battuta del BIOS)

root@spool:~# echo TEST > /dev/kmsg
root@spool:~# dmesg -T | tail -1
[Mon Feb 17 04:57:03 2014] TEST
root@spool:~# date
Mon Feb 17 11:45:17 CET 2014

Il server esegue ntp per la sincronizzazione dell'ora.

Qualcuno qui che sa come risolvere questo problema nel sistema operativo?

Linux spool 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux

Perché, quando si fa eco a /dev/kmsg, la data / ora del mio messaggio dmesgnon è sincronizzata con la data / ora del sistema?

Per verificare la tua teoria (che, a proposito, è valida), esegui quanto segue come root:

hwclock --show

Questo ti mostrerà il tuo orologio hardware sul server su cui stai eseguendo il comando.

Per sincronizzare l'orologio hardware con l'ora di sistema (che è gestita da NTTP), eseguire il comando seguente:

hwclock --systohc --utc

L'ultimo argomento (--utc) dice a hwclock di memorizzare l'ora nell'orologio hardware in un tempo universale coordinato.

Inoltre, tieni presente che la pagina man di dmesg (1) dice quanto segue, quindi il comportamento che stai riscontrando è documentato e valido:

   -T, --ctime
          Print human-readable timestamps.

          Be aware that the timestamp could be inaccurate!  The time
          source used for the logs is not updated after system
          SUSPEND/RESUME.

dmesg stampa il ringbuffer del kernel che registra i messaggi con uptime in pochi secondi dall'avvio come timestamp.

Pertanto, se si utilizza l'opzione -T, tutti questi valori di uptime vengono aggiunti alla data di avvio del sistema. Se hai avuto momenti in cui dormi in sospensione o riprendi, si perdono, quindi in questi casi l'opzione -T non è utile, poiché i valori di data / ora non sono corretti in quel momento e in passato.

Per ottenere tempi precisi per voci "recenti" dmesg, è possibile convertire i timestamp dmesg in tempo reale con un po 'di hacking dell'output.

Per "recente" intendo i tempi successivi all'ultima sospensione / ripresa, poiché (come già sottolineato da altri) i tempi di sospensione non vengono conteggiati nel timestamp di dmesg.

Ma se ne hai bisogno spesso, come su un notebook, potresti mettere qualcosa come il seguente in funzioni o alias:

# write current time to kernel ring buffer
echo "timecheck: $(date +%s) = $(date +%F_%T)" | sudo tee /dev/kmsg

# use our "timecheck" entry to get the difference
# between the dmesg timestamp and real time
offset=$(dmesg | grep timecheck | tail -1 \
| perl -nle '($t1,$t2)=/^.(\d+)\S+ timecheck: (\d+)/; print $t2-$t1')

# pipe dmesg output through a Perl snippet to
# convert it's timestamp to correct readable times
dmesg | tail \
| perl -pe 'BEGIN{$offset=shift} s/^\[(\d+)\S+/localtime($1+$offset)/e' $offset

# or use this instead to keep dmesg colors
dmesg --color=always | tail \
| perl -pe 'BEGIN{$offset=shift} s/^(\x1b\[.*?m)?\[(\d+)\S+/$1.localtime($2+$offset)/e' $offset

Uscita campione:

...
Sat Jun 29 11:12:28 2019 wlp3s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 10:5a:f7:53:1d:0f
Sat Jun 29 11:12:28 2019 IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
Sat Jun 29 11:34:16 2019 timecheck: 1561800856 = 2019-06-29_11:34:16
Sat Jun 29 12:10:11 2019 wlp3s0: cannot understand ECSA IE operating class, 5, ignoring

Rispetto dmesgall'output originale (che è spento per 3 giorni):

$ dmesg | tail -4
[249424.746958] wlp3s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 10:5a:f7:53:1d:0f
[249424.749662] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
[250732.318826] timecheck: 1561800856 = 2019-06-29_11:34:16
[252887.828699] wlp3s0: cannot understand ECSA IE operating class, 5, ignoring

$ dmesg -T | tail -4
[Wed Jun 26 17:59:09 2019] wlp3s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 10:5a:f7:53:1d:0f
[Wed Jun 26 17:59:09 2019] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
[Wed Jun 26 18:20:57 2019] timecheck: 1561800856 = 2019-06-29_11:34:16
[Wed Jun 26 18:56:52 2019] wlp3s0: cannot understand ECSA IE operating class, 5, ignoring