waktu dmesg vs waktu sistem tidak benar

Saya harap ada seseorang yang bisa membantu saya dengan masalah aneh ini.

Saya pikir saya tahu mengapa itu terjadi tetapi saya tidak tahu bagaimana menyelesaikannya. Mungkin itu karena waktu BIOS tidak diatur dengan benar atau sesuatu seperti itu. Tetapi saya tidak ingin mengubah waktu BIOS sekitar 400+ server. (Atau ubah batt 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

Server menjalankan ntp untuk sinkronisasi waktu.

Adakah yang tahu cara memperbaiki masalah ini di OS?

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

Mengapa, ketika menggema ke /dev/kmsg, tanggal / waktu pesan saya di dmesgtidak disinkronkan dengan tanggal / waktu sistem?

Untuk memverifikasi teori Anda (yang, omong-omong, suara), jalankan yang berikut ini sebagai root:

hwclock --show

Ini akan menunjukkan jam perangkat keras Anda di server Anda menjalankan perintah.

Untuk menyinkronkan jam perangkat keras Anda dengan waktu sistem Anda (yang dikelola oleh ntp), jalankan perintah berikut:

hwclock --systohc --utc

Argumen terakhir (--utc) memberi tahu hwclock untuk menyimpan waktu dalam jam perangkat keras dalam waktu universal terkoordinasi.

Selain itu, harap diingat bahwa halaman manual untuk dmesg (1) mengatakan yang berikut, sehingga perilaku yang Anda alami didokumentasikan dan valid:

   -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 hanya mencetak ringbuffer kernel yang mencatat pesan dengan uptime dalam hitungan detik agar tidak dimulai sebagai cap waktu.

Jadi, jika Anda menggunakan opsi -T, semua nilai uptime ini hanya ditambahkan ke tanggal sistem Anda di-boot. Jika Anda memiliki waktu tidur dalam penundaan atau melanjutkan, mereka hilang, jadi dalam kasus ini -T opsi tidak berguna, karena nilai tanggal / waktu tidak benar dan kembali di masa lalu.

Untuk mendapatkan waktu yang akurat untuk entri "baru" dmesg, Anda dapat mengubah cap waktu dmesg menjadi waktu nyata dengan beberapa peretasan dari keluaran.

Yang dimaksud dengan "baru-baru ini", maksud saya waktu setelah penangguhan / resume terakhir, karena (sebagaimana yang telah ditunjukkan sebelumnya) waktu penangguhan tidak dihitung dalam cap waktu dmesg.

Tetapi jika Anda sering membutuhkannya, seperti pada buku catatan, Anda dapat memasukkan sesuatu seperti yang berikut ke dalam fungsi atau 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

Output sampel:

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

Dibandingkan dengan dmesgoutput asli (yang dimatikan 3 hari):

$ 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