Какого дьявола!
Я в ярости!
За такой алгоритм работы clock я бы тому писателю руки без наркоза отрубил бы!
Выставил в clock всё в false. Не писать! Не читать! Не исправлять дрифт!
Ничего не делать! Дебил, ты понял!
Так кого же дьявола ты мне в system time наброс к hclock CMOS делаешь размером с tz?!!
Блин, заставил часы сидеть systime=CMOS
Но какой же конкретный костыль?!
Сервису clock нельзя сказать off, - он не chkconfig-совместимый.
Вырубил в /etc/sysconfig/clock всё в false
К тому что выше добавил
# cp /etc/cron.hourly/sysdatetimeset-n-hclocaltime /etc/rc.d/rc.local
Переписывать можно было - он пустой.
Файл естессно должен быть исполняемый. Иначе взлетать не будет.
Это довесок к тому, что выше.
ntpd остановить и вырубить.
После вырубания перед ребутом синхронизировать все часы:
# ntpdate -u timeserver && hwclock --localtime --systohc
Здесь есть засада:
после ребута, после взлёта dm, время в например kdm будет отображаться:
kdmtime=timeCMOS+tz
около секунды-полторы пока не отработает rc.local
А отрабатывать он будет всегда последним.
Вместо rc.local можно стырить идею отсюда:
http://forum.altlinux.org/index.php/topic,30444.msg217212.html#msg217212и затолкать сервис очередью пораньше, но после поднятия сетевого интерфейса, чтобы он успевал отрабатывать до завершения загрузки. Выигрыш по времени с как сервис есть, но секундное запоздание всё равно заметно.
При постоянном наличии сети, плюс здесь, еле видимый, но есть: вне зависимости от того кто и где накуролесит, после загрузки время в CMOS всегда будет равно времени системному. А тем более и после разгрузки.
timeserver лучше выбрать с минимальными пингами, чтобы соратить время запрос/ответ.
После этого, время в BIOS будет всегда равно системному.
Но костыль это конкретный. Мир ещё такого не видел.
Чтобы не было такого гемора, часы в BIOS надо держать всегда во всех осях в utc, а не в локальном.
Если дуалбутом Windows:
http://crashmag.net/configuring-windows-7-support-for-utc-bios-timeУ меня без виндовс попыткой держать при линукс время в биос локальное было вообще непредсказуемо.
Проблема уже поднималась
https://lists.altlinux.org/pipermail/mandrake-russian/2013-July/679959.htmlно так и осталась без ответа.