Таймеры systemd срабатывают с задержкой в 5 часов после перехода на localtime

Так, например, если на момент времени выполнения таймера системы не была запущена, то при следующем запуске выполнение происходит лишь через 5 часов, тогда как до этого они выполнялись сразу же (что и подразумевает опция persistent=true).

Похоже это баг. Попробуй написать об этом вот тут: https://github.com/systemd/systemd/issues.

upd. Кстати, а какой дистрибутив и какая версия systemd?

Похоже это баг

Почему же в таком случае systemctl list-timers --all явно указывает «+05»? Похоже, это явно ожидаемое поведение, но я не уверен, как с ним справиться.

Кстати, а какой дистрибутив и какая версия systemd?

Manjaro, systemd 242.

После смены UTC —> localtime

Что значит «смена UTC -> localtime»? Смена часового пояса системы?

таймеры systemd (fstrim, logrotate, man-db и т. д.). срабатывают на 5 часов позднее, чем нужно

А когда «нужно»?

Так, например, если на момент времени выполнения таймера системы не была запущена, то при следующем запуске выполнение происходит лишь через 5 часов, тогда как до этого они выполнялись сразу же (что и подразумевает опция persistent=true)

Ты уверен, что это именно задержка отложенного выполнения в 5 часов, а не просто потому что ты ошибся в расчётах и на самом деле пропущенных срабатываний не было?

Непосредственно само время выполнения тоже сместилось — с 19:00 на 00:00.

Это как раз очевидно: все таймеры, которые ты перечислил, написаны так, что они выполняются в 00:00 локального времени. Если часовой пояс на твоей системе был некорректно выставлен в +0 вместо +5, то 00:00 локального времени с точки зрения системы наступало как раз в 19:00 настоящего локального времени. Подумай — это соображение точно не объясняет все предыдущие проблемы?

Всем спасибо. Решил вопрос радикально: вернулся назад на UTC.
Теперь осталось заставить работать дуалбутный оффтопик с ним же...

Всем спасибо. Решил вопрос радикально: вернулся назад на UTC.

Блин, ну ты хоть расскажи как это воспроизвести. Интересно же поковырять.

это проще, дарю ключевые слова для гугла «windows utc hardware clock».
или даже прямой ответ https://wiki.archlinux.org/index.php/System_time#UTC_in_Windows

Если семерка и новее, то можно. Но лучше выкини ее.

Теперь осталось заставить работать дуалбутный оффтопик с ним же...

Мля, виндузятники такие невежды, ппц. Решение этого вопроса - ровесник тебя. Это просто три-ви-ально

В том-то и дело, что я не предпринимал ничего нестандартного. timedatectl set-local-rtc 1, и все таймеры сбились.

Но история в целом несколько длиннее: суть в том, что мой 60 Гб SSD разбит на 3 раздела (ESP, системный и ещё один для Windows на NTFS). По умолчанию в Manjaro TRIM постоянный, через опцию discard, но, насколько я понимаю, он не очень хорошо влияет на срок жизни SSD, поэтому я отказался в пользу TRIM'а раз в неделю с помощью fstrim. По умолчанию fstrim TRIM'ит все примонтированные разделы, но NTFS-раздел в GNU/Linux я не использую (а TRIM в оффтопике я полностью отключил), и он не монтируется при загрузке.

Казалось бы, это совершенно не проблема, т.к. достаточно включить его в fstab. Но ситуация несколько сложнее: в целях снижения уровня шума я отключаю (перевожу в idle, точнее) HDD с помощью hdparm, при этом, делаю это не автоматически, так как одному из моих HDD уже больше 7 лет, и слишком частые выключения негативно скажутся на сроке его службы. Иными словами, я примерно составляю план использования HDD (мысленно), и перевожу их в idle в случае неактивности в течение как минимум нескольких часов, чтобы уменьшить нагрузку на старый HDD (и на новый, но о старом я беспокоюсь больше).

Но и тут есть один интересный момент: по неизвестной причине диски выходят из idle при примонтировании любого раздела. Неважно какого и с какого диска. Иными словами, если случится внезапный fstrim для SSD, то он может «разбудить» HDD в неподходящий момент.

Тот факт, что о состоянии SSD я тоже забочусь, а также граничащее с обсессией нежелание держать примонтированными разделы, привели к тому, что я вручную выполняю fstrim --verbose на NTFS-раздел каждую неделю. Одновременно с этим, я проверяю, был ли TRIM'нут основной раздел (и ESP) через journalctl -r -b | grep trim и systemctl list-timers --all. В одном из таких случае я, пусть и не сразу, обнаружил задержку, которую описал в ОП.

timedatectl set-local-rtc 1, и все таймеры сбились.

ЯННП, ты сбил время на 5 часов и побежал на ЛОР жаловаться, что у тебя на пять часов сбились таймеры?

Приветики, противный ;) Зачем тебе Manjaro? Кривая система, поставь федорку, там таких проблем нет.

Чмоки *)

zvezdochiot