Постоянные сбои времени в Linux
Постоянные сбои времени в Linux
Ещё один глупый вопрос...
Итак господа, во3никла курьёзная, но в то же время крайне неприятная ситуация. Недавно мне пришлось полностью сбросить BIOS. Как следствие, все параметры сброшены на дефолтные, а дата и время по нулям. На десктопе две оси - оффтопная и линукс. Так вот, линукс стал вытворять со временем хер знает что. Причём, как это не прискорбно, заподозрен был в этом именно пингвин. Время в аппаратных часах устанавливается в localtime. Не знаю точно где, но если не ошибаюсь, в /etc/adjtime ведь хранится предыдущее сохранённое системное время? - так вот там тоже написано LOCAL, хотя я точно не знаю, к чему этот локал, т.к. просто не нашёл мана на adjtime, но полагаю, он подсказывает hwlock'у, что время в аппаратных часах - местное, а не UTC. Две последовательные перезагрузки часы как будто выдерживают, но вот если выключить машину, а потом включить на следующий день, снова уходим далеко в будущее - 10 июня, 2028 г. как Вам это? Мне не очень... Причём дата именно одна и та же, насколько я успел заметить. До этого всё было нормально. И вантуз так над временем не издевается... Короче, не знаю, что делать. Надоело каждый раз делать date MMDDHHmmYY; hwclock --adjust; hwclock --systohc. Как это можно побороть? В чём ещё могут быть грабли кроме /etc/adjtime? И он ли вообще виноват? По правде, сталкиваюсь с таким впервые - поэтому поставлен в тупик... /etc/localtime из /usr/share/timezone/Europe/Minsk
Итак господа, во3никла курьёзная, но в то же время крайне неприятная ситуация. Недавно мне пришлось полностью сбросить BIOS. Как следствие, все параметры сброшены на дефолтные, а дата и время по нулям. На десктопе две оси - оффтопная и линукс. Так вот, линукс стал вытворять со временем хер знает что. Причём, как это не прискорбно, заподозрен был в этом именно пингвин. Время в аппаратных часах устанавливается в localtime. Не знаю точно где, но если не ошибаюсь, в /etc/adjtime ведь хранится предыдущее сохранённое системное время? - так вот там тоже написано LOCAL, хотя я точно не знаю, к чему этот локал, т.к. просто не нашёл мана на adjtime, но полагаю, он подсказывает hwlock'у, что время в аппаратных часах - местное, а не UTC. Две последовательные перезагрузки часы как будто выдерживают, но вот если выключить машину, а потом включить на следующий день, снова уходим далеко в будущее - 10 июня, 2028 г. как Вам это? Мне не очень... Причём дата именно одна и та же, насколько я успел заметить. До этого всё было нормально. И вантуз так над временем не издевается... Короче, не знаю, что делать. Надоело каждый раз делать date MMDDHHmmYY; hwclock --adjust; hwclock --systohc. Как это можно побороть? В чём ещё могут быть грабли кроме /etc/adjtime? И он ли вообще виноват? По правде, сталкиваюсь с таким впервые - поэтому поставлен в тупик... /etc/localtime из /usr/share/timezone/Europe/Minsk
Ну какая работа со строками может быть в языке, название которого является не строкой, а символом? (c) Sergue E. Leontiev
Aleksey Kondratenko, в том-то и дело, что не нашёл я в мане по hwсlock ничего про удаление adjtime'a... Насколько я помню. Хотя может и не очень так уж внимательно прочитал А сохранение времени в аппаратные часы ессесно происходит... А что значит, система не использует --adjust? Разве оно не нужно для любой системы, для калибровки часов?
Но вообще, спасибо большое всем за советы, буду пробовать...
Но вообще, спасибо большое всем за советы, буду пробовать...
Ну какая работа со строками может быть в языке, название которого является не строкой, а символом? (c) Sergue E. Leontiev
Да, попутно, всё же хотелось бы не только исправить, но и понять причину такого поведения... Почему hwclock ведёт себя так безобразно? Ну, по идее ведь при настройке времени/даты через date можно сделать hwlock --systohc, потом обратно hwclock --hctosys чтобы заставить его работать с правильным временем и сохранить в adjtime это правильное время, но на практике такое шаманство не помогает... Почему нужно именно удалить adjtime?
Ну какая работа со строками может быть в языке, название которого является не строкой, а символом? (c) Sergue E. Leontiev
- Quantum
- Неотъемлемая часть форума
- Сообщения: 259
- Зарегистрирован: 20 мар 2006, 15:53
- Откуда: г. Минск
В /etc/adjtime записывается время и на сколько было изменено системное время. В последующем на основе этих данных высчитывается девиация RTC. Если несколько раз беспорядочно изменить время, система просто рассчитывает ошибочную девиацию, и сбивает часы, ты снова регулируешь их - и в следующий раз значение девиации снова изменяется, но остаётся ошибочным.
Выйти из этого круга можно только отрегулировав время, стерев adjtime, и начав всё заново, внося при помощи hwclock только незначительные изменения, связанные с естественной ошибкой RTC.
Выйти из этого круга можно только отрегулировав время, стерев adjtime, и начав всё заново, внося при помощи hwclock только незначительные изменения, связанные с естественной ошибкой RTC.
Sarge 3.1r0
Короче, ничерта не работает. Думал прибил эту идиотскую машину времени - не тут-то было. Опять та же история. Пингвин надо мной издевается. Идёт вполне нормальная загрузка (приблизительно, дословно не помню):
Using hardware clock as reference: [нормальная дата/время, допустим 22 Ноября 18:00 ЕЕТ 2006]
всё вроде нормально... и тут, немного погодя...
Setting system clock to 10 Jun 21:06 EEST 2028
пацталом.
Почему вообще именно эта идиотская дата всегда??? Откуда она может браться в принципе, если при шатдауне было сохранено правильное время? Кто ещё в линуксе может так пере***вать время? (извиняюсь за выражение, просто впервые за очень продолжительное время линукс вводит меня в форменное бешенство). Делал, как описано выше:
date [today-date]
rm /etc/adjtime
работаю до перезагрузки, потом по идее, время сохраняется при нормальном шатдауне из скрипта с помощью hwclock и всё равно со временем опять какая-то херня! То что проблема не с железными часами, ясно из загрузочного дампа: то самое Using hardware clock as reference [нормальная дата].
Подскажите, в чём ещё могут быть косяки? Ибо затрахался уже с этой машиной времени. Можно ли заставить забыть про его дурацкий интеллект в работе со временем, но чтобы DST было? Вантуз ведь не имеет такого мощного "интеллекта" для работы со временем (не поддерживает, якобы, timezones) но нормально справляется с DST. Гугл, к слову, не дал никаких внятных ответов по теме... Короче, в ауте.
Using hardware clock as reference: [нормальная дата/время, допустим 22 Ноября 18:00 ЕЕТ 2006]
всё вроде нормально... и тут, немного погодя...
Setting system clock to 10 Jun 21:06 EEST 2028
пацталом.
Почему вообще именно эта идиотская дата всегда??? Откуда она может браться в принципе, если при шатдауне было сохранено правильное время? Кто ещё в линуксе может так пере***вать время? (извиняюсь за выражение, просто впервые за очень продолжительное время линукс вводит меня в форменное бешенство). Делал, как описано выше:
date [today-date]
rm /etc/adjtime
работаю до перезагрузки, потом по идее, время сохраняется при нормальном шатдауне из скрипта с помощью hwclock и всё равно со временем опять какая-то херня! То что проблема не с железными часами, ясно из загрузочного дампа: то самое Using hardware clock as reference [нормальная дата].
Подскажите, в чём ещё могут быть косяки? Ибо затрахался уже с этой машиной времени. Можно ли заставить забыть про его дурацкий интеллект в работе со временем, но чтобы DST было? Вантуз ведь не имеет такого мощного "интеллекта" для работы со временем (не поддерживает, якобы, timezones) но нормально справляется с DST. Гугл, к слову, не дал никаких внятных ответов по теме... Короче, в ауте.
Ну какая работа со строками может быть в языке, название которого является не строкой, а символом? (c) Sergue E. Leontiev
Похоже, проблема устранена, причём совсем с другого конца - пока скачков времени не наблюдается (при тех условиях, при которых они появлялись ранее). Помогла пересборка ядра. Идёт разбирательство, что могло быть не так в конфигурации. Ещё раз всем спсб.
Ну какая работа со строками может быть в языке, название которого является не строкой, а символом? (c) Sergue E. Leontiev