мешает работе таймеры расписание резервное копирование

Пропущенное срабатывание таймера: Persistent и выключенная машина

Если в момент срабатывания машина выключена или systemd не работал, обычный таймер просто пропускает этот раз. Параметр Persistent=true заставляет выполнить пропущенный запуск сразу после загрузки — это то, чего ждут от ночных задач вроде резервного копирования.

Что это значит

Состояние последнего срабатывания systemd хранит в /var/lib/systemd/timers. По этим файлам он и понимает, что запуск был пропущен. Удаление их сбрасывает историю: при Persistent=true следующая загрузка вызовет запуск сразу.

Вероятные причины

По порядку: сверху то, что встречается чаще.

Машина была выключена в момент срабатывания

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

Механизм не копит очередь: за все пропущенные периоды задача выполнится однократно. Для суточных отчётов это может быть неожиданно.
Запуск пришёлся на момент загрузки и не состоялся

Сразу после включения машины могут быть недоступны сеть или диски, и задача падает. Persistent=true выполнит её один раз — и неудачно.

Диагностика

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

Столбцы LAST и PASSED показывают, когда таймер срабатывал в прошлый раз.

systemctl list-timers --all --no-pager

Файлы состояния таймеров: по времени изменения видно последнее учтённое срабатывание.

sudo ls -l /var/lib/systemd/timers/

Действующие настройки догона и разброса запусков.

systemctl show myapp.timer -p Persistent -p RandomizedDelaySec

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Машина была выключена в момент срабатывания

Почему происходит: Таймеры по календарю не догоняют пропущенное без явного указания. Для серверов с ночным обслуживанием и для ноутбуков это обычная ситуация.

Как проверить

Посмотрите прошлое срабатывание и время загрузки.

systemctl list-timers --all --no-pager | grep myapp
uptime -s

Как исправить

Добавьте Persistent=true в секцию [Timer]. После загрузки пропущенный запуск выполнится один раз.

[Timer]
OnCalendar=daily
Persistent=true

2. Несколько пропусков подряд выполняются одним запуском

Почему происходит: Механизм не копит очередь: за все пропущенные периоды задача выполнится однократно. Для суточных отчётов это может быть неожиданно.

Как проверить

Посмотрите записи о запусках службы за период.

journalctl -u myapp.service --since "7 days ago" --no-pager | grep -iE "started|finished" | tail

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

3. Запуск пришёлся на момент загрузки и не состоялся

Почему происходит: Сразу после включения машины могут быть недоступны сеть или диски, и задача падает. Persistent=true выполнит её один раз — и неудачно.

Как проверить

Посмотрите журнал службы вокруг времени загрузки.

journalctl -u myapp.service -b --no-pager | head -20

Как исправить

Отложите запуск после загрузки: добавьте OnBootSec= или зависимость от network-online.target.

[Timer]
Persistent=true
RandomizedDelaySec=300

Пример вывода

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

$ systemctl list-timers --all --no-pager
NEXT                        LEFT     LAST                        PASSED  UNIT          ACTIVATES
Tue 2026-09-16 00:00:00 MSK 9h left  Fri 2026-09-12 00:00:12 MSK 3 days  backup.timer  backup.service

Связанные ошибки

Таймер активен, но не срабатывает Таймер systemd в состоянии active, но служба не запускается. Разбор: нет условия срабатывания, таймер не включён, ошибка в OnCalendar.
Таймер не работает после перезагрузки Таймер работал, пока его запускали вручную, но после перезагрузки не активен: не выполнено включение или нет WantedBy=timers.target.
Failed to parse calendar expression: ошибка в OnCalendar systemd не разбирает календарное выражение таймера. Правила записи OnCalendar и проверка через systemd-analyze calendar.
Два таймера на одну службу: срабатывания накладываются Одна служба вызывается несколькими таймерами: запуски накладываются, часть срабатываний теряется.
Таймер срабатывает, но задача падает незаметно Таймер работает исправно, а задача каждый раз завершается ошибкой, и об этом никто не узнаёт. Как настроить оповещение через OnFailure.
clocksource: Marking clocksource unstable Ядро переключило источник времени. Службы видят скачки времени, таймеры срабатывают не тогда, когда ожидалось.
status=212/TIMERSLACK в systemd Код 212/TIMERSLACK: не удалось задать допуск таймеров процесса из TimerSlackNSec=. Редкий код.
Задача cron не выполняется Задача в crontab не запускается: короткий PATH, права на файл задачи, точка в имени файла, отсутствие перевода строки.

Источники

systemd.timer(5)
Persistent=, RandomizedDelaySec= и хранение состояния таймеров. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Проверено выключением тестовой машины на сутки: с Persistent=true запуск выполнился после загрузки. собственная проверка, systemd 255
сверено 15 сентября 2026