Час dmesg vs системний час не вірно

Я сподіваюся, що ось хтось може допомогти мені у цій дивній проблемі.

Я думаю, що я знаю, чому це відбувається, але я не знаю, як це вирішити. Можливо, це тому, що час BIOS не встановлено правильним або щось подібне. Але я не хочу змінювати час BIOS на приблизно 400+ серверах. (Або змінити бій 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

Сервер працює ntp для синхронізації часу.

Хтось тут знає, як виправити цю проблему в ОС?

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

Чому під час відлуння /dev/kmsgдата / час мого повідомлення dmesgне синхронізуються з датою / часом системи?

Щоб перевірити свою теорію (яка, до речі, звучить), виконайте наступне як root:

hwclock --show

Це покаже вам ваш апаратний годинник на сервері, на якому ви виконуєте команду.

Щоб синхронізувати годинник обладнання з вашим системним часом (яким керує ntp), виконайте таку команду:

hwclock --systohc --utc

Останній аргумент (--utc) говорить hwclock для зберігання часу в апаратному годиннику в узгоджений універсальний час.

Крім того, майте на увазі, що на сторінці man для dmesg (1) написано наступне, тож поведінка, яку ви переживаєте, задокументована та дійсна:

   -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 просто друкує ringbuffer ядра, який реєструє повідомлення з режимом роботи в секундах від запуску як часової позначки.

Тож якщо ви використовуєте опцію -T, всі ці значення часу безперервного часу просто додаються до дати завантаження вашої системи. Якщо ви коли-небудь спали у призупиненому або поновлюваному режимі, вони втрачаються, тому в цьому випадку -Т варіант не корисний, оскільки значення дати / часу не є правильними тоді і назад у минулому.

Щоб отримати точні часи для "останніх" записів dmesg, ви можете перетворити часові позначки dmesg в реальний час з деяким злому виводу.

Під "останнім часом" я маю на увазі часи після останнього призупинення / відновлення, оскільки (як інші вже вказували) періоди призупинення не враховуються у часовій позначці dmesg.

Але якщо вам це потрібно часто, як у зошиті, ви можете помістити щось подібне до функцій або псевдонімів:

# 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

Вибірка зразка:

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

Порівняно з вихідним dmesgвиходом (який вимкнено на 3 дні):

$ 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