Soluzione 1:
dmesg stampa semplicemente il ringbuffer del kernel che registra i messaggi con uptime in secondi dall'avvio come timestamp.
Quindi, se usi l'opzione -T, tutti questi valori di uptime vengono semplicemente aggiunti alla data in cui il tuo sistema è stato avviato. Se hai dormito in sospensione o ripresa, sono persi, quindi in questi casi l'opzione -T non è utile, poiché i valori di data/ora non sono corretti in quel momento e nel passato.
Soluzione 2:
Per verificare la tua teoria (che, tra l'altro, è 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 ntp), esegui il seguente comando:
hwclock --systohc --utc
L'ultimo argomento (--utc) indica a hwclock di memorizzare l'ora nell'orologio hardware in 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.
Soluzione 3:
Per ottenere tempi precisi per voci "recenti" in dmesg , potresti convertire i timestamp dmesg in tempo reale con un po' di hacking dell'output.
Per "recente", intendo i tempi dopo l'ultima sospensione/ripresa, poiché (come altri hanno già sottolineato) i tempi di sospensione non vengono conteggiati nel timestamp dmesg.
Ma se ne hai bisogno spesso, come su un taccuino, potresti inserire qualcosa di simile a quanto segue in funzioni o alias:
# write current time to kernel ring buffer so it appears in dmesg output
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
Esempio di output:
...
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 all'originale dmesg uscita (che è disattivata di 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