dmesg time vs system time time ist nicht korrekt

Ich hoffe, dass hier jemand ist, der mir bei diesem seltsamen Problem helfen kann.

Ich denke, dass ich weiß, warum es passiert, aber ich weiß nicht, wie ich es lösen soll. Vielleicht liegt es daran, dass die BIOS-Zeit nicht richtig eingestellt ist oder so ähnlich. Aber ich möchte die BIOS-Zeit von ungefähr 400+ Servern nicht ändern. (Oder ändern Sie das BIOS Batt)

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

Der Server führt ntp für die Zeitsynchronisation aus.

Weiß jemand hier, wie man dieses Problem im Betriebssystem behebt?

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

Warum werden /dev/kmsgDatum und Uhrzeit meiner eingehenden Nachricht dmesgnicht mit Datum und Uhrzeit des Systems synchronisiert?

Um Ihre Theorie zu verifizieren (die übrigens vernünftig 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 Hardwareuhr mit Ihrer Systemzeit (die von ntp verwaltet wird) zu synchronisieren:

hwclock --systohc --utc

Das letzte Argument (--utc) weist hwclock an, die Uhrzeit in der Hardware-Uhr in der koordinierten Weltzeit zu speichern.

Beachten Sie außerdem, dass in der Manpage für dmesg (1) Folgendes steht, damit das aufgetretene Verhalten 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.

dmesg druckt nur den Kernel-Ringpuffer, der Nachrichten mit einer Betriebszeit von Sekunden nach dem Start als Zeitstempel protokolliert.

Wenn Sie also die Option -T verwenden, werden alle diese Werte für die Betriebszeit nur zu dem Datum hinzugefügt, an dem Ihr System gestartet wurde. Wenn Sie Zeiten hatten, in denen Sie im Suspend- oder Resume-Modus geschlafen haben, gehen diese verloren. In diesem Fall ist die Option -T nicht sinnvoll, da Datums- / Zeitwerte nicht in der Vergangenheit liegen.

Um genaue Zeiten für "aktuelle" Einträge in zu erhalten dmesg, können Sie die dmesg-Zeitstempel mit einigem Hacking der Ausgabe in Echtzeit konvertieren.

Mit "kürzlich" meine ich Zeiten nach der letzten Unterbrechung / Wiederaufnahme, da (wie andere bereits darauf hingewiesen haben) Unterbrechungszeiten nicht im dmesg-Zeitstempel gezählt werden.

Wenn Sie es jedoch häufig benötigen, wie auf einem Notebook, können Sie Funktionen oder Aliasnamen wie die folgenden hinzufügen:

# 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

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 zur Originalausgabe dmesg(die um 3 Tage abweicht):

$ 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