dmesg zamanı vs sistem zamanı zamanı doğru değil

Umarım burada bu garip problemde bana yardımcı olabilecek biri vardır.

Sanırım neden olduğunu biliyorum ama nasıl çözeceğimi bilmiyorum. Belki de BIOS zamanının doğru ayarlanmamış olması veya bunun gibi bir şey olabilir. Ama yaklaşık 400+ sunucunun BIOS zamanını değiştirmek istemiyorum. (Veya BIOS battını değiştirin)

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

Sunucu zaman senkronizasyonu için ntp çalıştırıyor.

Burada işletim sisteminde bu sorunu nasıl çözeceğini bilen var mı?

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

Neden yankılanırken, iletimin /dev/kmsgtarihi / saati dmesgsistem tarihi / saati ile senkronize edilmiyor?

Teorinizi doğrulamak için (bu arada, sağlamdır) aşağıdakileri kök olarak yürütün:

hwclock --show

Bu, komutu yürüttüğünüz sunucudaki donanım saatinizi gösterir.

Donanım saatinizi sistem saatinizle (ntp tarafından yönetilir) senkronize etmek için aşağıdaki komutu çalıştırın:

hwclock --systohc --utc

Son argüman (--utc), hwclock'a zamanı koordine edilmiş evrensel zamanda donanım saatinde saklamasını söyler.

Ayrıca, dmesg (1) için man sayfasının aşağıdakileri söylediğini, dolayısıyla yaşadığınız davranışın belgelendiğini ve geçerli olduğunu lütfen unutmayın:

   -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, mesajları zaman damgası olarak başlatıldıktan sonra saniyeler içinde çalışma süresi ile kaydeden çekirdek ringbuffer'ı yazdırır.

-T seçeneğini kullanırsanız, tüm bu çalışma süresi değerleri sisteminizin önyüklendiği tarihe eklenir. Askıya alma veya devam ettirme sırasında uyuyan zamanlarınız varsa, bunlar kaybolur, bu nedenle bu durumda -T seçeneği yararlı değildir, çünkü tarih / saat değerleri geçmişte ve sonra doğru değildir.

dmesgİçindeki "son" girişler için doğru süreleri elde etmek için , dmesg zaman damgalarını çıktının bazı hacklenmesi ile gerçek zamana dönüştürebilirsiniz.

"Son zamanlarda" derken, son askıya alma / devam ettirmeden sonra geçen zamanlar (diğerlerinin de işaret ettiği gibi) askıya alma süreleri dmesg zaman damgasında sayılmaz.

Ancak, bir dizüstü bilgisayarda olduğu gibi, sık sık ihtiyacınız varsa, işlevlere veya takma adlara aşağıdakine benzer bir şey koyabilirsiniz:

# 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

Örnek çıktı:

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

Orijinal çıktıyla karşılaştırıldığında dmesg(3 gün kapalıdır):

$ 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