LINUX.ORG.RU
решено ФорумAdmin

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

 , ,


0

2

Тихо и незаметно подкрался ещё один косяк. С тех пор, когда я последний раз настраивал дуалбут, управление временем было передано в systemd, а эти обладатели мудрых фасеточных глаз по какой то причине решили, что при синхронизации времени через ntp не требуется переводить аппаратные часы. Так я узнал, что Local time и RTC time это отдельные понятия и всегда были.

За возвращение нормального поведения в теории должна отвечать timedatectl set-local-rtc 0 с опцией --adjust-system-clock, только это не работает. Другой полезной информации найти не удалось - яндекс упорно предлагает интрукции по настройке systemd-tymesyncd.

Перемещено hobbit из general

★★★★★

Последнее исправление: hobbit (всего исправлений: 1)

а эти обладатели мудрых фасеточных глаз по какой то причине решили, что при синхронизации времени через ntp не требуется переводить аппаратные часы

Кто сказал?

Так я узнал, что Local time и RTC time это отдельные понятия и всегда были

Это не просто отдельные понятия, это тёплое и мягкое.

За возвращение нормального поведения в теории должна отвечать timedatectl set-local-rtc 0 с опцией –adjust-system-clock, только это не работает

Опиши, что ты хочешь получить в конечном итоге.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)

дуалбут

Мне кажется, причина в этом. Венда, насколько я знаю, по умолчанию всегда держит системные часы в локальном времени. Есть вроде ключ реестра, который заставляет венду держать системные часы в UTC. Тогда всё работает корректно в дуалбуте.

eternal_sorrow ★★★★★
()

Ничего не знаю об этих ваших системдах, но вообще-то ядро синхронизирует аппаратные часы (RTC) с локальным временем (взятым от ntp или ещё откуда-то) каждые 11 минут, если RTC_SYSTOHC не отключено в конфиге. И об этом написано абсолютно везде, где идёт речь о времени под линуксами, например, в мане по hwclock. В этих же мануалах рекомендуют при дуалбуте: во-первых, отключать виндовую автосинхронизацию времени, а во-вторых, таки да, настроить RTC материнки на UTC вместо местного времени, и сообщить об этом винде (способ, AFAIK, зависит от версии винды).

alegz ★★★★
()
Последнее исправление: alegz (всего исправлений: 1)
Ответ на: комментарий от eternal_sorrow

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

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от intelfx

Чтобы ntpdate pool.ntp.org снова переводил аппаратные часы на правльное время по uts. Без всяких ручных --settime xx.yy.zz aa:bb:cc

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 2)
Ответ на: комментарий от Dimez

Опередил.

Всю жизнь аппаратные часы были отвязаны от операционки и надо было запускать <…>

Почти. Если в ядре установлен флаг, что системные часы «синхронизированы с реальным временем», то ядро само обновляет RTC каждые 11 минут.

Но чтобы этот флаг был взведён, в системе должен постоянно работать NTP-демон. Если просто время от времени запускать ntpdate, то этот флаг взведён не будет.

intelfx ★★★★★
()
Ответ на: комментарий от alegz

ядро синхронизирует аппаратные часы (RTC) с локальным временем (взятым от ntp или ещё откуда-то) каждые 11 минут, если RTC_SYSTOHC не отключено в конфиге.

Судя по всему этот режим ещё надо включить. Точнее в моём случае его не надо включать, потому что он предназначен для систем с непрерывно запущенным демоном ntp, а мне скорее всего нужно старое поведение с вызовом hwclock --systohc при выключении системы.

А идеальней всего было бы прямо в ntpdate включить вызов той же самой функции, но тут уже хз, то ли раньше так и было, то ли hwclock --systohc при выключении и всё работало.

написано абсолютно везде, где идёт речь о времени под линуксами, например, в мане по hwclock

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

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от kirill_rrr

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

Как-то так получается. Хотя уже объяснили, что для корректного сохранения времени ядром нужен NTP-сервис.

anonymous
()
Ответ на: комментарий от anonymous

Не, нужно вернуть систему в то состояние, когда ты подаёшь одну команду на синхронизацию времени от руки раз в несколько лет, когда на аппаратных часах возникает заметное глазу отклонение. А держать запущенным специального демона, который будет использовать сложные хаки для калибровки милисекундной точности - не нужно.

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от kirill_rrr

подаёшь одну команду на синхронизацию времени от руки раз в несколько лет

Как-то не бьётся с вопросом про скрипты при выключении. Раз в несколько лет можно запустить hwclock.

На самом деле, конечно, заметное глазу отклонение порядка одной-двух секунд на типичных RTC может вылезти за какие-то дни, но спорить с ненужнистами смысла не вижу.

anonymous
()
Ответ на: комментарий от anonymous

Как-то не бьётся с вопросом про скрипты при выключении. Раз в несколько лет можно запустить hwclock.

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

Меня напрягает когда кто то где то решает сделать простые вещи сложными. Оно просто работало 15 лет в любых дистрибутивах. Я хз как. Мне не нужно было знать ничего кроме date и ntpdate, и никаких отдельных демонов, а все скрипты и юниты на типовой простейший случай уже были в системе.

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Меня напрягает когда кто то где то решает сделать простые вещи сложными

И сейчас это просто

Оно просто работало 15 лет в любых дистрибутивах

И сейчас работает

Мне не нужно было знать ничего кроме date и ntpdate

Сейчас не нужно знать и это, служба справляется за тебя

HerbertHoover
()
Ответ на: комментарий от kirill_rrr

Ну фейспалм же. NTP, который крутится примерно в каждом устройстве на этом шарике, ты называешь сложным хаком, а самописные костыли, которые при всём этом строго хуже — нет.

intelfx ★★★★★
()
Ответ на: комментарий от HerbertHoover

И сейчас это просто

Нет, всё ещё проще записать связку ntpdate + hwclock -w в хроне.

И сейчас работает

Если бы работало - у меня бы автоматом восстановились бы часы.

служба справляется за тебя

Там этих служб как говна. И с каждой зачем то приходится разбираться. А некоторые вообще вредоносные, gpg-agent например.

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от intelfx

А ты читал всю эту портянку про подстройку дрифта? Которая абсолютно бессмысленна если у тебя не сервер 24/7 и которая просто не будет работать если не залезть туда руками и не перевести её в наиболее подходящий режим, а в мануале так и написано - лучше рассчитайте и вбейте коэфицент дрифта вручную.

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Что не решит проблему, а будет просто переводить время на рэндомноезначение (вероятнее всего +-5 часов назад) при каждой загрузке? Что кстати косяк для корневой ФС. А ещё - висеть в памяти процессом.

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

hwclock и NTP связаны примерно никак (я тебе о том и говорю, что вместо возни с hwclock-легаси поставил бы NTP-клиента). Ты лучше читай не портянки, а то, на что отвечаешь.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Клиент у меня уже есть, это ntpdate. Тут нужен демон с функцией записи аппаратных часов. И он почти наверняка будет вызывать для этого тот же hwclock. А даже если не будет - нужен именно клиент а не демон.

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

И он почти наверняка будет вызывать для этого тот же hwclock

В твоей теме даже цитаты приводили на эту тему. Нет, не будет.

нужен именно клиент а не демон

У systemd-timesyncd вообще нет серверного режима, это чистый клиент.

anonymous
()
Ответ на: комментарий от kirill_rrr

hwclock --systohc

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

anc ★★★★★
()
Ответ на: комментарий от kirill_rrr

Ты смешной. Ты одновременно рассказываешь, как раньше было хорошо, а теперь всё сломали, и как тебе не хочется использовать «сложные хаки для калибровки милисекундной точности». А юмор в том, что раньше в ходу были именно сложные хаки (просто ты их не замечал, потому что они были спрятаны под капот и/или ты был нубасом), а сейчас принято использовать NTP и не любить мозг.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Сервер и демон - разные вещи.

Ничосе! Я хочу сказать, какая тебе вообще разница, запускается оно время от времени, или работает постоянно? Никакой лишней (серверной) функциональности там нет. При этом ntpdate руками или по расписанию — это полное говно, потому что у тебя регулярно будет ситуация типа «time jumped backwards» из-за мгновенной корректировки времени.

anonymous
()
Ответ на: комментарий от anonymous

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

Раньше - это насколько раньше в годах?

Когда постоянное подключение к интернету было экзотикой.

Это да, согласен полностью.

anc ★★★★★
()
Ответ на: комментарий от anonymous

потому что у тебя регулярно будет ситуация типа «time jumped backwards» из-за мгновенной корректировки времени.

С чего бы это? Если за час системные часы настолько сбоят, то имхо что-то не то именно с системными часами.

anc ★★★★★
()