heure dmesg vs heure système n'est pas correcte

J'espère que voici quelqu'un qui pourra m'aider avec ce problème étrange.

Je pense que je sais pourquoi cela se produit mais je ne sais pas comment le résoudre. C'est peut-être parce que l'heure du BIOS n'est pas réglée correctement ou quelque chose comme ça. Mais je ne veux pas changer l'heure du BIOS d'environ 400+ serveurs. (Ou changez le 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

Le serveur exécute ntp pour la synchronisation de l'heure.

Quelqu'un ici qui sait comment résoudre ce problème dans le système d'exploitation?

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

Pourquoi, en écho à /dev/kmsg, la date / heure de mon message dmesgn'est pas synchronisée avec la date / heure système?

Pour vérifier votre théorie (qui, soit dit en passant, est valable), exécutez ce qui suit en tant que root:

hwclock --show

Cela vous montrera votre horloge matérielle sur le serveur sur lequel vous exécutez la commande.

Pour synchroniser votre horloge matérielle avec votre heure système (qui est gérée par ntp), exécutez la commande suivante:

hwclock --systohc --utc

Le dernier argument (--utc) indique à hwclock de stocker l'heure dans l'horloge matérielle en temps universel coordonné.

De plus, veuillez garder à l'esprit que la page de manuel de dmesg (1) dit ce qui suit, donc le comportement que vous rencontrez est documenté et valide:

   -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 imprime simplement le tampon du noyau qui enregistre les messages avec une disponibilité en quelques secondes à partir du démarrage comme horodatage.

Donc, si vous utilisez l'option -T, toutes ces valeurs de disponibilité sont simplement ajoutées à la date de démarrage de votre système. Si vous avez eu des heures de sommeil en suspension ou en reprise, elles sont perdues, dans ce cas, l'option -T n'est pas utile, car les valeurs de date / heure ne sont pas exactes à ce moment-là et reviennent dans le passé.

Pour obtenir des heures précises pour les entrées "récentes" dans dmesg, vous pouvez convertir les horodatages dmesg en temps réel avec un piratage de la sortie.

Par "récent", je veux dire les temps après la dernière suspension / reprise, car (comme d'autres l'ont déjà souligné) les temps de suspension ne sont pas comptés dans l'horodatage dmesg.

Mais si vous en avez besoin souvent, comme sur un ordinateur portable, vous pouvez mettre quelque chose comme ce qui suit dans des fonctions ou des 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

Exemple de sortie:

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

Par rapport à la dmesgsortie d' origine (qui est éteinte de 3 jours):

$ 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