thời gian dmesg so với thời gian hệ thống không chính xác

Tôi hy vọng rằng đây là ai đó có thể giúp tôi với vấn đề kỳ lạ này.

Tôi nghĩ rằng tôi biết tại sao nó lại xảy ra nhưng tôi không biết làm thế nào để giải quyết nó. Có thể đó là do thời gian BIOS không được đặt chính xác hoặc đại loại như thế. Nhưng tôi không muốn thay đổi thời gian BIOS của hơn 400 máy chủ. (Hoặc thay đổi 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

Máy chủ đang chạy ntp để đồng bộ hóa thời gian.

Có ai ở đây biết cách khắc phục vấn đề này trong HĐH không?

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

Tại sao, khi lặp lại /dev/kmsg, ngày / giờ tin nhắn của tôi dmesgkhông được đồng bộ hóa với ngày / giờ hệ thống?

Để xác minh lý thuyết của bạn (trong đó, nhân tiện, là âm thanh), thực hiện như sau với quyền root:

hwclock --show

Điều này sẽ cho bạn thấy đồng hồ phần cứng của bạn trên máy chủ mà bạn đang thực hiện lệnh.

Để đồng bộ hóa đồng hồ phần cứng của bạn với thời gian hệ thống của bạn (được quản lý bởi ntp), hãy chạy lệnh sau:

hwclock --systohc --utc

Đối số cuối cùng (--utc) cho biết hwclock lưu trữ thời gian trong đồng hồ phần cứng theo thời gian phổ quát phối hợp.

Ngoài ra, xin lưu ý rằng trang man cho dmesg (1) nói như sau, vì vậy hành vi bạn đang gặp phải được ghi lại và hợp lệ:

   -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 chỉ in ra ringbuffer kernel ghi nhật ký các tin nhắn với thời gian hoạt động trong vài giây từ khi được bắt đầu như dấu thời gian.

Vì vậy, nếu bạn sử dụng tùy chọn -T, tất cả các giá trị thời gian hoạt động này sẽ được thêm vào ngày hệ thống của bạn được khởi động. Nếu bạn có thời gian ngủ trong trạng thái treo hoặc tiếp tục, chúng sẽ bị mất, vì vậy trong trường hợp này, tùy chọn -T không hữu ích, vì các giá trị ngày / giờ không đúng lúc đó và quay lại quá khứ.

Để có thời gian chính xác cho các mục "gần đây" dmesg, bạn có thể chuyển đổi dấu thời gian dmesg sang thời gian thực với một số hack đầu ra.

Theo "gần đây", tôi có nghĩa là thời gian sau lần đình chỉ / tiếp tục cuối cùng, vì (như những người khác đã chỉ ra) thời gian đình chỉ không được tính vào dấu thời gian dmesg.

Nhưng nếu bạn cần nó thường xuyên, như trên một cuốn sổ tay, bạn có thể đặt một cái gì đó như sau vào các hàm hoặc bí danh:

# 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

Đầu ra mẫu:

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

So với dmesgsản lượng ban đầu (giảm 3 ngày):

$ 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