Solución 1:
dmesg simplemente imprime el búfer de anillo del kernel que registra mensajes con tiempo de actividad en segundos desde que se inician como marca de tiempo.
Entonces, si usa la opción -T, todos estos valores de tiempo de actividad se agregan a la fecha en que se inició su sistema. Si tuvo horas durmiendo en suspender o reanudar, se pierden, por lo que en estos casos la opción -T no es útil, ya que los valores de fecha/hora no son correctos en ese momento y retroceden al pasado.
Solución 2:
Para verificar su teoría (que, por cierto, es sólida), ejecute lo siguiente como root:
hwclock --show
Esto le mostrará el reloj de su hardware en el servidor en el que está ejecutando el comando.
Para sincronizar el reloj de su hardware con la hora de su sistema (que es administrada por ntp), ejecute el siguiente comando:
hwclock --systohc --utc
El último argumento (--utc) le dice a hwclock que almacene la hora en el reloj de hardware en tiempo universal coordinado.
Además, tenga en cuenta que la página del manual para dmesg(1) dice lo siguiente, de modo que el comportamiento que está experimentando esté documentado y sea válido:
-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.
Solución 3:
Para obtener tiempos precisos para entradas "recientes" en dmesg , podría convertir las marcas de tiempo de dmesg en tiempo real con alguna piratería de la salida.
Por "reciente", me refiero a los tiempos posteriores a la última suspensión/reanudación, ya que (como otros ya señalaron) los tiempos de suspensión no se cuentan en la marca de tiempo de dmesg.
Pero si lo necesita con frecuencia, como en un cuaderno, podría poner algo como lo siguiente en funciones 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
Salida de muestra:
...
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
Comparado con el dmesg original salida (que está desactivada por 3 días):
$ 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