Lösung 1:
dmesg gibt nur den Kernel-Ringbuffer aus, der Meldungen mit Betriebszeit in Sekunden seit dem Start als Zeitstempel protokolliert.
Wenn Sie also die Option -T verwenden, werden all diese Betriebszeitwerte einfach zum Bootdatum Ihres Systems hinzugefügt. Wenn Sie Schlafzeiten in Suspend oder Resume hatten, gehen diese verloren, daher ist die Option -T in diesen Fällen nicht sinnvoll, da Datums-/Uhrzeitwerte nicht richtig sind und in der Vergangenheit liegen.
Lösung 2:
Um Ihre Theorie zu überprüfen (die übrigens stichhaltig ist), führen Sie Folgendes als root aus:
hwclock --show
Dies zeigt Ihnen Ihre Hardware-Uhr auf dem Server, auf dem Sie den Befehl ausführen.
Führen Sie den folgenden Befehl aus, um Ihre Hardware-Uhr mit Ihrer Systemzeit (die von ntp verwaltet wird) zu synchronisieren:
hwclock --systohc --utc
Das letzte Argument (--utc) weist hwclock an, die Zeit in der Hardwareuhr in koordinierter Weltzeit zu speichern.
Denken Sie außerdem bitte daran, dass die Manpage für dmesg(1) Folgendes sagt, damit das Verhalten, das Sie erleben, dokumentiert und gültig ist:
-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.
Lösung 3:
Um genaue Zeiten für "neueste" Einträge in dmesg zu erhalten , könnten Sie die dmesg-Zeitstempel in Echtzeit umwandeln, indem Sie die Ausgabe hacken.
Mit "kürzlich" meine ich Zeiten nach dem letzten Suspend/Resume, da (wie andere bereits darauf hingewiesen haben) Suspend-Zeiten nicht im dmesg-Zeitstempel gezählt werden.
Aber wenn Sie es oft brauchen, wie auf einem Notebook, könnten Sie etwas wie das Folgende in Funktionen oder Aliase stecken:
# 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
Beispielausgabe:
...
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
Im Vergleich zum ursprünglichen dmesg Ausgang (der um 3 Tage ausgeschaltet ist):
$ 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