Solution 1 :
dmesg imprime simplement le tampon annulaire du noyau qui enregistre les messages avec le temps de disponibilité en secondes à partir du démarrage en tant qu'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 moments de sommeil en suspension ou en reprise, ils sont perdus, donc dans ce cas, l'option -T n'est pas utile, car les valeurs de date/heure ne sont pas correctes à ce moment-là et remontent dans le passé.
Solution 2 :
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, gardez à l'esprit que la page de manuel de dmesg(1) indique ce qui suit, afin que le comportement que vous rencontrez soit 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.
Solution 3 :
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 peu de piratage de la sortie.
Par "récent", j'entends les temps après la dernière suspension/reprise, puisque (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 souvent besoin, comme sur un ordinateur portable, vous pouvez mettre quelque chose comme ce qui suit dans les fonctions ou les 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
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 à l'original dmesg sortie (qui est décalée 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