La hora de dmesg frente a la hora del sistema no es correcta

Espero que haya alguien que pueda ayudarme con este extraño problema.

Creo que sé por qué está sucediendo, pero no sé cómo resolverlo. Tal vez sea porque el tiempo del BIOS no está configurado correctamente o algo así. Pero no quiero cambiar el tiempo de BIOS de aproximadamente más de 400 servidores. (O cambie la batería 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

El servidor ejecuta ntp para sincronización horaria.

¿Alguien aquí que sepa cómo solucionar este problema en el sistema operativo?

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

¿Por qué, al hacer eco /dev/kmsg, la fecha / hora de mi mensaje dmesgno está sincronizada con la fecha / hora del sistema?

Para verificar su teoría (que, por cierto, es sólida), ejecute lo siguiente como root:

hwclock --show

Esto le mostrará su reloj de hardware en el servidor donde está ejecutando el comando.

Para sincronizar su reloj de hardware con su hora del sistema (que es administrado 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 hora universal coordinada.

Además, tenga en cuenta que la página de manual de dmesg (1) dice lo siguiente, para 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.

dmesg solo imprime el kernel ringbuffer que registra los mensajes con tiempo de actividad en segundos desde que se inicia 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 ha tenido momentos de suspensión o suspensión, se pierden, por lo que en este caso, la opción -T no es útil, ya que los valores de fecha / hora no son correctos en ese momento.

Para obtener tiempos precisos para las entradas "recientes" dmesg, puede convertir las marcas de tiempo dmesg a tiempo real con algún hackeo de la salida.

Por "reciente", me refiero a los tiempos posteriores a la última suspensión / reanudación, ya que (como ya señalaron otros) los tiempos de suspensión no se cuentan en la marca de tiempo dmesg.

Pero si lo necesita con frecuencia, como en un cuaderno, puede poner algo como lo siguiente en funciones 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

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

En comparación con la dmesgsalida original (que está apagada 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