Я надеюсь, что здесь есть кто-то, кто может помочь мне с этой странной проблемой.
Я думаю, что знаю, почему это происходит, но не знаю, как это решить. Возможно, это потому, что время BIOS установлено неправильно или что-то в этом роде. Но я не хочу менять время BIOS примерно 400+ серверов. (Или поменять батт биоса)
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 не синхронизируется с системной датой / временем?
dmesg просто печатает кольцевой буфер ядра, который регистрирует сообщения с временем безотказной работы в секундах с момента запуска в качестве отметки времени.
Поэтому, если вы используете параметр -T, все значения времени безотказной работы просто добавляются к дате загрузки вашей системы. Если у вас были времена, когда вы спали в режиме ожидания или возобновления, они теряются, поэтому в этих случаях опция -T бесполезна, так как значения даты / времени не верны тогда и не вернулись в прошлое.
Чтобы проверить свою теорию (которая, кстати, верна), выполните от имени пользователя root:
hwclock --show
Это покажет вам ваши аппаратные часы на сервере, на котором вы выполняете команду.
Чтобы синхронизировать аппаратные часы с системным временем (которым управляет ntp), выполните следующую команду:
hwclock --systohc --utc
Последний аргумент (--utc) указывает hwclock хранить время в аппаратных часах по всемирному координированному времени.
Кроме того, имейте в виду, что страница руководства для 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, вы можете преобразовать временные метки dmesg в реальное время, взломав вывод.
Под «недавним» я подразумеваю время после последней приостановки / возобновления, поскольку (как уже указали другие) время приостановки не учитывается в метке времени dmesg.
Но если вам это нужно часто, например, на ноутбуке, вы можете добавить в функции или псевдонимы что-то вроде следующего:
# write current time to kernel ring buffer so it appears in dmesg output
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