Постоянно сбивается «date» в ArchLinux.

ntpd

часы в системе utc или local?
если настройка rc.conf не совпадает с реальным положением вещей, будет такой эффект.

Часы локалтайм. Таймзона верная. Но я, кажется, понял, что hwclock!=date

Вы скопировали файл зоны или сделали ссылку из '/usr/share/zoneinfo/' в /etc/localtime ?

Часы локалтайм.

Дуалбут?

Вы скопировали файл зоны или сделали ссылку из '/usr/share/zoneinfo/' в /etc/localtime ?

В Арче это в rc.conf прописывается.

Покажите вывод:

#hwclock --utc
#hwclock --local

Прописывается оно может и прописывается, но создание символьной ссылки или копирование файла зоны /etc/localtime это стандартное действие.

создание символьной ссылки или копирование файла зоны /etc/localtime это стандартное действие.

Ничего там копировать не надо.

Я, например, просто написал в rc.conf

HARDWARECLOCK="localtime"
TIMEZONE="Europe/Moscow"

ТС, если в /etc/rc.conf в секции DAEMONS нет hwclock, то правь/не правь время и дату, после перезагрузки все равно все будет по-старому.

я, кажется, понял, что hwclock!=date

Естественно: при загрузке система запускает системный таймер, исходя из значения hwclock. Потом работает только системный таймер (который точнее), а при выключении компьютера hwclock (если его не забыть в DAEMONS прописать) «загоняет» системное время в часики биоса.

[quoote] Потом работает только системный таймер (который точнее) Сомнительно. Linux просто корректно не может напрямую работать с hwclock, в особенности если у вас CPU разогнан.

«загоняет» системное время в часики биоса.

Не обязательно.

Вот выдержка из вашего /etc/rc.sysinit

etc/rc.sysinit: # If TIMEZONE is not set in rc.conf, the timezone stored in /etc/localtime

Ещё раз вам говорю, что создание ссылки или копирование файла зоны в /etc/localtime - это стандартный для Unix/Linux метод выставления параметров времени.

По-моему, проще указать на стадии настройки системы TIMEZONE в rc.conf, чем что-то куда-то копировать.

По-моему мнению , по-твоему мнению, это одно, но вы отрицаете стандартный механизм.

В то время, как проще запомнить несколько стандартных способов настройки, чем помнить, что в Archlinux это настраивается так, в Debian, к примеру, по-другому, в другом дистрибутиве ещё как-то иначе. Думаю вы меня поняли.

К томуже выполнить 'cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime' возможно будет быстрее, если использовать клавишу 'TAB'.

Хе-хе, у меня, оказывается, еще и так:

ll /etc/localtime
lrwxrwxrwx 1 root root 33 апр.  16 17:37 /etc/localtime -> /usr/share/zoneinfo/Europe/Moscow

Постоянно сбивается «date» в ArchLinux. (комментарий)

Можно и копировать и ссылкой, ссылкой отчасти лучше, при обновлении пакета tzdata не нужно заново копировать файл зоны.

у меня тоже вчера на нетбуке сбилось на свежеустановленной системе. помогло hwclock -s (хардовые часы шли нормально, сбилось системное только)

в особо запущенных случаях помогало раньше удалять hwclock в /var/*/

Нету... Вернусь домой- выставлю и попробую. если не поможет-закину сюда всю запрошенную инфу

Прописывается оно может и прописывается, но создание символьной ссылки или копирование файла зоны /etc/localtime это стандартное действие.

...в котором в данном случае просто нет необходимости.

Вы так в этому уверены ?

Посмотрите, в вашей системе так же есть ссылка '/etc/localtime -> /usr/share/zoneinfo/*/*' хотя вручную вы её не создавали, её создаёт один из стартовых сценариев, основываясь на данных, которые вы указали в '/etc/rc.conf', в частности в переменной 'TIMEZONE'. Даже значение этой переменной является частью адреса файла в директории '/usr/share/zoneinfo/'.

Вы так в этому уверены ?

Посмотрите, в вашей системе так же есть ссылка '/etc/localtime -> /usr/share/zoneinfo/*/*' хотя вручную вы её не создавали, её создаёт один из стартовых сценариев, основываясь на данных, которые вы указали в '/etc/rc.conf', в частности в переменной 'TIMEZONE'.

Ну, вы же сами сейчас мои слова подтвердили. Создавать ссылку не нужно, так как скрипт создаст её сам. Я, вот, даже не знал о существовании такой ссылки, а время у меня правильное.

Что интересно, винда то же самое творит
Подписался

Как, кстати, с этим бороться в дуалбуте?

Прочитайте это моё сообщение: Постоянно сбивается «date» в ArchLinux. (комментарий)

Я, вот, даже не знал о существовании такой ссылки, а время у меня правильное.

А сколько лет вы уже используете Linux/Unix? Это стандартный механизм, все остальные способы это обёртки над ним, в сообщении которое я указал представлена часть комментария из /etc/rc.sysinit.

Как, кстати, с этим бороться в дуалбуте?

Держать время в одном и том же формате в обеих системах.

У вас указано, что системные часы показывают utc или localtime ?

Прочитайте это моё сообщение: Постоянно сбивается «date» в ArchLinux. (комментарий)

Я его читал.

А сколько лет вы уже используете Linux/Unix?

Немного, около 5 лет.

Это стандартный механизм, все остальные способы это обёртки над ним, в сообщении которое я указал представлена часть комментария из /etc/rc.sysinit.

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

я вроде ставил localtime в расчете на то, что дуалбута не будет. utc нужно поставить? и куда его писать?

Axon

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

Это, конечно, правильно, но разработчики так же оставили поддержку использования стандартного способа указания временной зоны, который не конфликтует с механизмами, которые предоставляют разработчики дистрибутива:

# If TIMEZONE is not set in rc.conf, the timezone stored in /etc/localtime

что тоже является хорошим тоном.

Так что, прежде чем разбираться была ли выполнена дистрибутиво зависимая настройка, проще предложить использовать стандартный способ настройки для выявления проблемы и последующей донастройки, в соответствии с требованиями дистрибутива, или оставить так как есть. Опять же я не отрицаю использования дистрибутивных механизмов.

Это, конечно, правильно, но разработчики так же оставили поддержку использования стандартного способа указания временной зоны, который не конфликтует с механизмами, которые предоставляют разработчики дистрибутива:

За это я и люблю Арч. :-)

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

Тут согласен, да. Теперь ясно, почемы вы настаивали на этом варианте.

Вам нужно выставить как раз localtime.

Или в Windows указать, что в аппаратных часах время храниться в формате UTC, а в Linux указать так же UTC.

Я в биосе поставил UTC и винду приучил 4 часа к этому времени прибавлять, а не менять время аппаратное

Ну значит в Linux укажите, что в BIOS (аппаратных часах) указано UTC.

Тааак... UTC равен реальному времени в моем часовом поясе, а local равен тому времени, на которое сбиваются часы. Как я вижу, это я накосячил, а не с ними что-то не так. Как мне поменять параметры местами?:все должно быть наоборот.

Выставил hwclock --localtime в время моего часового пояса. Теперь все ок, но hwclock --utc показывает время на 4 часа _больше_. Так и должно быть? Ведь у Москвы сдвиг +4, так что, если localtime- 14часов, то utc должен быть 10, а у меня-18.

Да, у тебя же localtime, поэтому сдвиг в другую сторону.

Понял, спасибо

У меня дуалбут. Если я побываю на винде(погонять в игрушку, которая под Linux'ом не взлетает), время сбивается на час назад: И hwclock и date. в /etc/rc.conf выбрано localtime. hwclock добавлен в список демонов. и hwclock и date установлены в мое реальное время(ну, то, которое в моем часовом поясе). Что делать?

Само не сбивается(это исправили тут), сбивается только если в винде побывать.

В то время, как проще запомнить несколько стандартных способов настройки, чем помнить, что в Archlinux это настраивается так, в Debian, к примеру, по-другому, в другом дистрибутиве ещё как-то иначе. Думаю вы меня поняли.

Пакеты тоже ставить будете все с помощью make install. Ведь пакетные менеджеры разные от дистрибутива к дистрибутиву.

Как я понимаю, за корректировку времени отвечает /var/lib/hwclock/adjtime. Интересно, что будет, если его удалить и забить симлинк на /dev/null..?

Вот опять- ребутнулся ради проверки в винду. Было 8 часов N минут. Стало 4 часа N минут. Ну как...?