Настройка времени в linux

Установи в BIOS местное время и в /etc/hwclock выстави UTC=0

Наврал, править надо /etc/default/rcS, UTC=no

Такого файла у меня нет.

Добавил. Всё равно показывает неправильно время по сравнению с биосом на 3 часа вперёд. А когда ntp синхронизирует правильное время, в биосе сбивается на три часа назад...

Это очень вредный совет.

Предлагается делать так, как описано здесь: https://wiki.archlinux.org/index.php/Time#UTC_in_Windows.

А именно: аппаратные часы в UTC и заставить винду следовать этому же принципу. И отключить в винде синхронизацию времени.

Наврал, править надо /etc/default/rcS, UTC=no

Не помню, как в wheezy, а в тестинге это выкинули уже. Теперь надо в /etc/adjtime менять строку UTC на LOCAL.

А вообще да, UTC в RTC — лучше всего.

А вообще да, UTC в RTC — лучше всего.

Только есть минус: после загрузки сообщения в логах от ядра в UTC, пока система настройки таймзоны не считает.

Хм... Специально нашел в логах последнюю перезагрузку — всё ОК, время местное. Пруф. В kernel.log тоже. rsyslogd, как видно.

rsyslogd, как видно.

По барабану должно быть, по идее. Значит, что-то ещё не так. Либо rsyslog заранее считает, что время в UTC в начале загрузки. А если в BIOS выставить местоное, всё равно остаётся нормальное ?

А если в BIOS выставить местоное, всё равно остаётся нормальное ?

Ну, проверять мне щас лень, это ж надо два раза перезагружаться — сначала проверить, потом вернуть обратно. На фиг.

Прямо таки вредный?
Тогда расскажи уж, какие реальные профиты от UTC в биосе?
(кроме того, что не работает синхронизация времени в windows)

В файле /etc/adjtime меняешь UTC на LOCAL.

# ntpdate server

# /etc/init.d/hwclock.sh restart

Профит.

Сценарий: меняется таймзона или значение DST и система аварийно выключается до первой записи в RTC.

Сценарий: что-то пытается работать с файлами на диске до прочтения /etc/localtime. Результат — некорректные таймстампы.

Скажешь, мол, всё это хрень? Кому как. Если метод 1 по сравнению с методом 2 допускает хотя бы один сценарий фейла, то метод 1 — уже дерьмо.

Если метод 1 по сравнению с методом 2 допускает хотя бы один сценарий фейла, то метод 1 — уже дерьмо.

Пока вижу, метод 2 - дерьмо, т.к. не полностью поддерживается шиндошс.
Ещё один минус приведен выше

после загрузки сообщения в логах от ядра в UTC, пока система настройки таймзоны не считает

что-то пытается работать с файлами на диске до прочтения /etc/localtime. Результат — некорректные таймстампы.

В юзерспейсе всё запускается уже после чтения /etc/localtime

и система аварийно выключается до первой записи в RTC

Это когда и с каким софтом такое может быть?

Вот с DST, кстати, да, когда обе системы могут перевести время (не зная о том, что оно переведено).
В общем, не всё так однозначно

ТС, попробуй решение отсюда Забыл где устанавливаются параметры времени (комментарий).

Мне в свое время помогло, тоже очень долго мучился.

Отпишетесь потом пожалуйста, помогло или нет.

Самому интересно, вдруг положительный результат в моем случае, простое совпадение ;-)

Никаких изменений нет.

Не пойдёт, синхронизация нужна.

LOCAL прописан, ntp удалён от греха подальше. Не помогает.

Так включить синхронизацию в линуксе.

Спасибо. Вроде помогло. Посмотрим не будет ли сбиваться в дальнейшем.

Пакеты ntp и ntpdate нужны обязательно. Написанное мною выше работает на 100%, было лично проверено много раз.