Возникла интересная ситуация - не из разряда критичных, а скорее из разряда «да как так то!»
Есть сервер, на нем есть dmesg и он спешит на полчаса.
~ # echo TEST > /dev/kmsg && dmesg -T | tail -1 && date
[Чтв Ноя 30 13:03:38 2017] TEST
Чтв Ноя 30 12:29:35 MSK 2017
Первоначально я предположил, что в момент старта машины в биосе было выставлено неправильное время, а потом оно поправилось ntp (аптайм - 200 дней, что там было - не известно), но по прямым (who -b) и косвенным признакам (stat /proc/1) удалось установить, что время при старте машины было правильным и оно соответствует текущему времени минус аптайм.
Более того, сложилась такая парадоксальная картина:
Они не совсем одинаковые по способу получения, и про такое поведение гуглится. Но точного объяснения почему временные метки сообщений ядра и uptime расходятся не находится, никому не охото изучать ради этого исходники ядра.
Я читал о том, что dmesg может отставать - но никак не о том, что он может опережать :) Это и удивляет.
Точное объяснение может кто-то знает (потому что интересовался или потому что однажды встретил этот факт в т.ч. какой-нибудь переписке) - вдруг кто тут объявится и расскажет.
Заодно второй вопрос уже практического смысла - есть способ побороть это и сделать так, чтобы dmesg начал выдавать правильное время?)
