[Решено] Странное поведение hardware часов (сбиваются на время кратное -4 ч.)

[DmitrySPb]

Какая-то непонятная штука происходит с часами.

После перезагрузки они сбиваются на целое число часов, причем разное - утром сбивались на -8 часов, сейчас - на -4 часа. Вчера время тоже сбивалось, но не обратил внимания на сколько. Когда началось не знаю, заметил просто потому, что ноут не был к инету подключен, и время не синхронизировалось по NTP.

На всякий случай снова выполнил настройки из handbook, не помогло.

Стоит московский часовой пояс, локальное время (не UTC).

До этого несколько лет было норм.

[Bizdelnick]

Не дуалбут случайно?

[DmitrySPb]

Не дуалбут случайно?

В смысле нет ли параллельно стоящей винды? Или что?

Винда есть, поэтому в настройках и стоит local, а не UTC, впрочем винду я месяца 2 назад грузил последний раз. В BIOS время верное стоит, кстати.
Сейчас после перезагрузки так и вовсе на -12 часов сбилось...

[Bizdelnick]

В смысле нет ли параллельно стоящей винды? Или что?

Да.

в настройках и стоит local, а не UTC

С такой настройкой вечно проблемы, в самых разных дистрибутивах. Как чинить в Gentoo - это уже вопрос не ко мне.

[DmitrySPb]

Ну да с UTC такого нет, но мне удобней с local
В принципе не страшно, можно пару минут после включения с неправильным временем пожить, но непорядок, знаете ли

Причем проблема - из-за hwclock... вот сейчас он мне заявляет, что аппаратные часы установлены по UTC, хотя в /etc/conf.d/hwclock указано local.
Т.е., впечатление такое, что он при выключении считает, что работает по UTC и ставит -4 часа, а при включении, что по local и ничего уже не прибавляет.
Но почему он так считает... и поэтому ли выставляется неверное время - вопрос...

update от 27 сент: скорее всего грешил на сам hwclock зря, во всяком случае в момент, когда hw-часы сбиваются, hwclock не запускается... да и про UTC после того, как я заново все перенастроил он больше не врал...

[drBatty]

На всякий случай снова выполнил настройки из handbook, не помогло.

установите правильно timezone. Важно: timezone нужно инициализировать ДО загрузки графики. Иначе она покажет неправильное время (а вот в терминале запущенном ПОСЛЕ время будет правильным). Читайте рукокнигу про старт вашей DE/WM. Там обычно этот момент прописан,

Т.е., впечатление такое, что он при выключении считает, что работает по UTC

так и есть. Видать $TZ задаётся уже после.

Причем проблема - из-за hwclock... вот сейчас он мне заявляет, что аппаратные часы установлены по UTC,

не. у железных часов ОДНО время. Это ВЫ решаете, что это такое по вашему. Там обычно вообще нет такого деления. Т.е. UTC задаётся в команде.

-u, --utc

--localtime
Indicates that the Hardware Clock is kept in Coordinated Universal Time or
local time, respectively. It is your choice whether to keep your clock in
UTC or local time, but nothing in the clock tells which you've chosen. So
this option is how you give that information to hwclock.

If you specify the wrong one of these options (or specify neither and take a
wrong default), both setting and querying of the Hardware Clock will be
messed up.

If you specify neither --utc nor --localtime, the default is whichever was
specified the last time hwclock was used to set the clock (i.e. hwclock was
successfully run with the --set, --systohc, or --adjust options), as
recorded in the adjtime file. If the adjtime file doesn't exist, the
default is UTC time.

[DmitrySPb]

установите правильно timezone. Важно: timezone нужно инициализировать ДО загрузки графики. Иначе она покажет неправильное время (а вот в терминале запущенном ПОСЛЕ время будет правильным). Читайте рукокнигу про старт вашей DE/WM. Там обычно этот момент прописан,

У меня KDE, какой конкретный мануал, хендбук, мантру я должен прочитать?
Отрывок из messages

Sep 17 02:49:45 localhost syslog-ng[1919]: syslog-ng shutting down; version='3.4.2'
Sep 16 23:53:15 localhost syslog-ng[1916]: syslog-ng starting up; version='3.4.2'

Реальное время появления второго сообщения - 7-53, 17 Sep. Т.е. логирование возобновляется уже с неверным временем.

не. у железных часов ОДНО время. Это ВЫ решаете, что это такое по вашему. Там обычно вообще нет такого деления. Т.е. UTC задаётся в команде.

Есть файл # /etc/conf.d/hwclock, где параметр clock может быть либо UTC, либо local, либо железные часы интерпретируются как UTC, либо показывают местное время.
У меня этот параметр имеет значение local - т.е. у меня в BIOS стоит местное (локальное) время.

Код: Выделить всё

sudo hwclock --debug

А тут утверждается, что

Аппаратные часы выставлены по UTC времени

Впрочем, через N минут там же

Аппаратные часы выставлены по местному времени

От чего это зависит не знаю.

Применил способ решения проблемы: аля, снеси все и настрой заново, 2 раза вроде нормально, впрочем, днем я нечто подобное уже делал, было норм, а потом снова проблема.

[Bizdelnick]

Реальное время появления второго сообщения - 7-53, 17 Sep. Т.е. логирование возобновляется уже с неверным временем.

Вероятно, когда оно заканчивается, в аппаратные часы уже записано неверное время. Хотя системное может быть правильным.

[DmitrySPb]

возможно

[drBatty]

мантру я должен прочитать?

мантра: ВРЕМЯ ВСЕГДА ОДНО.

У вас две штуки часов:

1. железные.
2. программные.

Соответственно, если я живу по МСК(для простоты -- вы тоже. Если нет, переведите мои +4 в ваши), возможно 4(четыре) комбинации, и ВСЕ четыре правильные:

1. железные выставлены по UTC, как и программные
2. железные UTC программные МСК
3. железные МСК, программные UTC
4. железные МСК, программные МСК

Ключи --utc и --localtime нужны ТОЛЬКО для вариантов (2) и (3). Тогда утилита hwclock будет переделывать время так как надо (читайте мантру!). Т.е. если вариант №2, то hwclock вычитает 4 из железных часов и пишут туда МСК-4 (если у меня 10 часов, то в железные пишется 6, читайте мантру! Это тоже самое, что 10 часов в МСК, что 6 часов по UTC)

Естественно, варианты №1 и №4 самые простые, и именно их и надо юзать.

Естественно, если система и все юзеры в одном поясе, выбирается вариант №4.

Но есть одна тонкость: можно выбрать вариант №1, но считать, что это №4. Так тоже работает. До поры, до времени. Пока например венда не перепутает. Ну и в KDE тоже время можно задать, потому, если выбрать №1 (всё в UTC), то KDE показывает его как МСК+4, т.к. считает, что вы в МСК, и соответственно плюсует +4.

Но в вашем случае, вы видимо настроили №2 и №3, вот у вас время и перепиливается. Причём настроили вы не везде, а только где-то. Потому перепилка времени происходит не всегда.

Читайте мантру. ВРЕМЯ ВСЕГДА ОДНО. Однако, клиент хочет поставить МСК, и что-бы система сама перевела стрелки так, как это принято в МСК.

[drBatty]

А тут утверждается, что

часы сами не знают, как они выставлялись. Они пишут "нас поставили так, как будто в программных часах было локальное время".

Сами попробуйте выполнить hwclock --hctosys --utc, и время прыгнет вперёд на +4.

Исправляется hwclock --hctosys --localtime, время прыгнет назад на localtime. Значит всё правильно, и у вас вариант №4.

Сохраняться время должно как hwclock --systohc --localtime (выключение/гибернация)

Читать время надо hwclock --hctosys --localtime (запуск/проснуться)

Часы в BIOS надо ставить локально, ну и таймзону тоже надо прописать, у меня МСК
(таймзону скажет команда date, важно помнить, что она может быть разной даже для процессов. Т.е. скажем терминал в одной, а часы в КДЕ -- в другой)

[Bizdelnick]

Соответственно, если я живу по МСК(для простоты -- вы тоже. Если нет, переведите мои +4 в ваши), возможно 4(четыре) комбинации, и ВСЕ четыре правильные:

1. железные выставлены по UTC, как и программные
2. железные UTC программные МСК
3. железные МСК, программные UTC
4. железные МСК, программные МСК

Системное время (то есть время программных часов) - это число секунд с начала эпохи UNIX. Никакой часовой пояс тут ни при чём. Тут Вы правы:

ВРЕМЯ ВСЕГДА ОДНО

Четыре варианта есть в другом месте:

• При запуске системы hwclock --hctosys запускается с --utc, при остановке hwclock --systohc запускается также с --utc. Это нормальный способ, когда по соседству нет винды.
• При запуске системы hwclock --hctosys запускается с --localtime, при остановке hwclock --systohc запускается также с --localtime. Это костыль, нужный для мирного сожительства с виндой.
• При запуске системы hwclock --hctosys запускается с --localtime, а при остановке hwclock --systohc запускается с --utc. Это неправильно, в UTC+4 при каждой перезагрузке будет наблюдаться отставание на 4 часа.
• При запуске системы hwclock --hctosys запускается с --utc, а при остановке hwclock --systohc запускается с --localtime. Это неправильно, в UTC+4 при каждой перезагрузке будет наблюдаться убегание на 4 часа.

[DmitrySPb]

Костыльным способом проблему решил, но причина не ясна.

Подойдем к поиску причин возникновения проблемы логически.

Исходные данные: gentoo+KDE

Как теоретически должно все это работать?

1. Включаем ПК - системное время берется из железного, учитывая local или UTC, делается это одним из скриптов, которые запускаются при старте системы
2. Работаем на ПК - системное время поддерживается ОС с коррекцией по ntp
3. Выключаем ПК - системное время может быть записано в железное, а может и не быть, зависит от настроек.

Если я не прав, поправьте.

Настройки hwclock хранятся в /etc/conf.d/hwclock, где указывается часовой пояс, какое время (UTC или local) показывают железные часы, надо ли сбрасывать при выключении системные часы в железные.
В моем случае это Московский часовой пояс, железные часы установлены по местному времени, системное время при выключении записывается в железное.

Последнее - это и есть костыль, т.е. при выключении я тупо корректирую железное время, которое может быть неправильным. Изначально тут стояло NO.

Как на практике? При включении и выключении так и работает,
НО, железные часы сбрасываются на -4 часа (к UTC) с непонятной частотой во время работы системы. Тупо написал скрипт, который периодически снимает показания с железных часов:

Ср. 18 сент. 2013 12:26:17 -0.578737 секунд
Ср. 18 сент. 2013 08:28:27 -0.313316 секунд

Потом еще раз поймал:

Ср. 18 сент. 2013 13:18:52 -1.000635 секунд
Ср. 18 сент. 2013 09:19:23 -1.000897 секунд

После чего уже 2 часа нормально...

[Bizdelnick]

Последнее - это и есть костыль, т.е. при выключении я тупо корректирую железное время, которое может быть неправильным. Изначально тут стояло NO.

Это не костыль, а нормальное поведение - корректировка железных часов на случай, если они немного спешат/отстают, а системное время корректируется ntpd.

железные часы сбрасываются на -4 часа (к UTC) с непонятной частотой во время работы системы

А вот это очень странно. В crontab ничего интересного не прописано? Можно вообще погрепать по всему /etc: fgrep -R hwclock /etc.

[DmitrySPb]

Это не костыль, а нормальное поведение - корректировка железных часов на случай, если они немного спешат/отстают, а системное время корректируется ntpd.

Костыль в том смысле, что саму проблему это не решает, а лишь избавляет от последствий.

А вот это очень странно. В crontab ничего интересного не прописано? Можно вообще погрепать по всему /etc: fgrep -R hwclock /etc.

По расписанию ничего...
грепал /etc, hwclock там только в скрипте, который при старте запускается - устанавливает системное время, в частности...

Есть такая штука как adjtime, может она шалит? Попробовал отключить - понаблюдаю...

[drBatty]

1. Включаем ПК - системное время берется из железного, учитывая local или UTC, делается это одним из скриптов, которые запускаются при старте системы
2. Работаем на ПК - системное время поддерживается ОС с коррекцией по ntp
3. Выключаем ПК - системное время может быть записано в железное, а может и не быть, зависит от настроек.

Если я не прав, поправьте.

всё так.

железные часы установлены по местному времени, системное время при выключении записывается в железное. Последнее - это и есть костыль

Ну не знаю. Всегда и все так делают. Программное время по любому точнее, ну и с ntpd оно вообще идеальное. А вот железное время зависит от всего подряд. В частности от температуры, и очень сильно. Я уж не говорю про севшую батарейку.

НО, железные часы сбрасываются на -4 часа (к UTC) с непонятной частотой во время работы системы.

наверное криво настроен ntpd, который думает, что у вас UTC. Вот он и вычитает -4 из вашего localtime'а, о котором он не знает.

который периодически снимает показания с железных часов:

а железные-то зачем? они НЕ должны меняться во время работы.

[drBatty]

Костыль в том смысле, что саму проблему это не решает, а лишь избавляет от последствий.

что вы называете "проблемой"? У меня всё работает.
Т.е. проблема в ваших настройках.

Есть такая штука как adjtime, может она шалит?

а это-то вам зачем? Эта штука нужна для древних серверов без интернета и ntpd. Отключите её пожалуйста, и не включайте. Это если часы скажем спешат РОВНО на 10 секунд за мес. То там оно прописывается. И переводит так, что-бы в месяц получилось на 10 сек. меньше. Древность короче. Я настраивал как-то лет 10 назад, даже успешно. Подробностей не помню.

[Bizdelnick]

Есть такая штука как adjtime, может она шалит?

Эмм... А что это? Судя по всему, не adjtime(3)...

наверное криво настроен ntpd

ntpd не трогает железные часы, он корректирует только системное время.

[DmitrySPb]

Ну не знаю. Всегда и все так делают. Программное время по любому точнее, ну и с ntpd оно вообще идеальное. А вот железное время зависит от всего подряд. В частности от температуры, и очень сильно. Я уж не говорю про севшую батарейку.

Не нужно говорить про всех... по умолчанию в файле настроек стояло значение NO, я просто уже стал выяснять что значит каждый из параметров, на него наткнулся... Железные часы менее точны, это да, но убегай они на разное время - это одно, а тут четко 4 часа.

наверное криво настроен ntpd, который думает, что у вас UTC. Вот он и вычитает -4 из вашего localtime'а, о котором он не знает.

ntpd меняет системное время и меняет его правильно...

а железные-то зачем? они НЕ должны меняться во время работы.

Так в том то и дело, что меняются почему-то

что вы называете "проблемой"?

Проблема - это странное поведение железных часов, которые почему-то корректируются... Можно ликвидировать последствия, сбрасывая в них системное время, но тут мне уже просто интересно выяснить причины такого поведения...

а это-то вам зачем? Эта штука нужна для древних серверов без интернета и ntpd. Отключите её пожалуйста, и не включайте.

Да я как-то не очень пока и понял как оно включается и выключается, вернее как проверить включено или нет, в любом случае коррекция там нулевая стоит... Поэтому вряд ли дело в этом.

Пока курю ман hwclock, там что-то про ядро было, но пока не понял чего оно там делает...

Еще надо более подробно стартовые скрипты глянуть, хотя... сброс не всегда происходит сразу после перезагрузки...

[DmitrySPb]

пока не было времени заниматься...
поставил auditd, несанкционированного запуска hwclock он не фиксирует,
в стартовые скрипты вставил "маячки", там тоже ок, запускается с localtime

надо ядро другое поставить. поглядеть, как с ним...

[drBatty]

Проблема - это странное поведение железных часов, которые почему-то корректируются...

в любом случае коррекция там нулевая стоит... Поэтому вряд ли дело в этом.

ну вот у вас и получается UTC+0.

[drBatty]

надо ядро другое поставить. поглядеть, как с ним...

facepalm

[DmitrySPb]

drBatty
Вам поумничать хочется или все-таки помочь? Если первое, то делайте это в другом месте.

ну вот у вас и получается UTC+0.

Читайте ман: в первой строке файла /etc/adjtime содержится 3 числа - дрифт (секунды/сутки), время последней коррекции и 0 (для совместимости)
В третьей - Local или UTC, у меня - Local, поэтому какие еще UTC+0?

facepalm

Читаем ман: есть режим "11-minute mode", когда hardware clock автоматически корректируется ядром примерно каждые 11 минут.
Вот только по ману возможные значения переменной time_status ядра сумма каких-то из след. значений - 1,2,4,...,4096, но у меня 8193 (8192+1)... Что это значит непонятно... В мане описание для 1 и 2 версии ядра, для третьей нет... Может 8192 появилось в третьем?...
Там же сказано, что если "64" бит равен 0 - режим включен, у меня - 0, значит включен, но поскольку описание для второго ядра, то а черт его знает!.. В третьем ядре все вообще может быть по-другому...

[/dev/random]

!	Предупреждение от модератора
	Вырезал большую часть флейма (а именно, то, что можно было вырезать, не затрагивая основного обсуждения). Пожалуйста, придерживайтесь темы. drBatty, к вам это особенно относится.

[/dev/random]

DmitrySPb, проверьте, не включена ли в ядре опция CONFIG_RTC_SYSTOHC (не путать с CONFIG_RTC_HCTOSYS). Если включена, выключите.

[DmitrySPb]

DmitrySPb, проверьте, не включена ли в ядре опция CONFIG_RTC_SYSTOHC (не путать с CONFIG_RTC_HCTOSYS). Если включена, выключите.

Ага, как раз ядро "новое" в стейбл ветке появилось - на нем и попробую.

[NickLion]

А почему не использовать UTC? Windows позволяет его использовать тоже, хотя настройка и скрыта в реестре.

[Bizdelnick]

А почему не использовать UTC? Windows позволяет его использовать тоже, хотя настройка и скрыта в реестре.

Когда я пытался (давно) так делать, XP глючила адски.
С тех пор что-то изменилось?

[DmitrySPb]

А почему не использовать UTC? Windows позволяет его использовать тоже, хотя настройка и скрыта в реестре.

Да тут уже дело просто в том, чтобы найти причину странного поведения железных часов...

Когда я пытался (давно) так делать, XP глючила адски.
С тех пор что-то изменилось?

В windows примерно от Vista SP2 стало вроде норм с этим, а в XP - да, порой начинались проблемы.

[NickLion]

Когда я пытался (давно) так делать, XP глючила адски.
С тех пор что-то изменилось?

Да, на Win7 и Win8 никаких глюков замечено не было.