Persistent у таймера systemd: догоняющий запуск не является очередью пропущенных периодов
Увеличить схему
Фотография конкретного исполнения не приложена.
Если компьютер выключен во время календарного задания, система должна определить, что делать с пропуском. Persistent сохраняет время последнего срабатывания таймера. При следующей активации служба запускается, если за время неактивности таймер должен был сработать хотя бы один раз.
Справочник 262 ограничивает действие Persistent календарными таймерами с OnCalendar. Этот механизм не обещает отдельную активацию для каждого пропущенного интервала. Кроме того, догоняющее срабатывание остаётся под действием RandomizedDelaySec. Поэтому слово «сразу» в общей схеме нельзя трактовать как отсутствие любой дополнительной задержки при настроенном распределении нагрузки.
Для отчётов по каждому часу или суткам приложение должно самостоятельно учитывать обработанные периоды. Время срабатывания таймера и отметка успешного результата задания — разные данные. Если служба запустилась и завершилась ошибкой, сохранённое срабатывание не превращает незавершённый прикладной период в обработанный.
В приёмке выключают тестовый узел на несколько ожидаемых интервалов и проверяют поведение после возвращения. Сверяют число запусков и перечень действительно созданных результатов. Если бизнес-процесс требует восстановить все пропущенные периоды, это оформляют как явный алгоритм приложения с собственным учётом, а не как предполагаемое свойство одной строки Persistent=true.
Основание — Official systemd manual edition262, cited sections only, разделы systemd.timer Persistent; RandomizedDelaySec. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Материал относится к справочникам systemd 262. Установленные Linux-дистрибутив, сборка systemd и возможности ядра не проверялись; изменения служб и настроек не выполнялись.
Запросы отправляются на наш e-mail из вашей почтовой программы.
