hora dmesg vs hora do sistema não está correta

Espero que aqui esteja alguém que possa me ajudar com esse problema estranho.

Eu acho que sei por que isso está acontecendo, mas não sei como resolvê-lo. Talvez seja porque o tempo do BIOS não está definido corretamente ou algo parecido. Mas não quero alterar o tempo do BIOS de aproximadamente 400 + servidores. (Ou mude a bateria do 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

O servidor está executando o ntp para sincronização de horário.

Alguém aqui sabe como resolver esse problema no sistema operacional?

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

Por que, ao ecoar /dev/kmsg, a data / hora da minha mensagem dmesgnão é sincronizada com a data / hora do sistema?

Para verificar sua teoria (que, a propósito, é sólida), execute o seguinte como root:

hwclock --show

Isso mostrará o relógio do hardware no servidor em que você está executando o comando.

Para sincronizar o relógio do hardware com a hora do sistema (gerenciada pelo ntp), execute o seguinte comando:

hwclock --systohc --utc

O último argumento (--utc) diz ao hwclock para armazenar a hora no relógio do hardware na hora universal coordenada.

Além disso, lembre-se de que a página de manual do dmesg (1) diz o seguinte, para que o comportamento que você está enfrentando seja documentado e 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.

O dmesg apenas imprime o ringbuffer do kernel que registra as mensagens com tempo de atividade em segundos a partir do início como carimbo de data / hora.

Portanto, se você usar a opção -T, todos esses valores de tempo de atividade serão adicionados à data em que seu sistema foi inicializado. Se você dormiu várias vezes em suspensão ou retomada, elas serão perdidas; portanto, nesses casos, a opção -T não será útil, pois os valores de data / hora não estão corretos e voltam ao passado.

Para obter horários precisos para entradas "recentes" dmesg, você pode converter os carimbos de data / hora do dmesg em tempo real com alguns hackers na saída.

Por "recente", quero dizer tempos após a última suspensão / retomada, pois (como outros já apontaram) os tempos de suspensão não são contados no carimbo de data / hora do dmesg.

Mas se você precisar com frequência, como em um notebook, poderá colocar algo como o seguinte em funções ou aliases:

# 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

Saída de amostra:

...
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

Em comparação com a dmesgsaída original (que é desativada em 3 dias):

$ 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