Таймер продолжает запускать падающую службу
Состояние таймера не зависит от результата задания. Таймер остаётся работоспособным, даже если задание падает месяцами. Признак нормальной работы — не состояние таймера, а результат последних запусков службы.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Состояние таймера не отражает результат задания
Таймер отвечает только за момент запуска. Провал задания на него не влияет.
-
Отказ не порождает оповещения
Без указания действия при отказе провал задания остаётся только в журнале, а журнал никто не читает по расписанию.
-
Задание накладывается само на себя
Если прошлый запуск ещё идёт, новое срабатывание не запускает второй экземпляр, а ставит задачу в очередь. При регулярном превышении времени очередь растёт.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Когда сработает в следующий раз и когда срабатывал.
systemctl list-timers mytask.timer --no-pagerРезультат каждого запуска за неделю.
journalctl -u mytask.service --since "7 days ago" --no-pager | grep -iE "Started|Failed|Succeeded"Действие при отказе и результат последнего запуска.
systemctl show mytask.service -p OnFailure -p ResultРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Таймер отвечает только за момент запуска. Провал задания на него не влияет.
- Как проверить
-
Посмотрите состояние таймера и результат службы отдельно.
systemctl is-active mytask.timer; systemctl is-failed mytask.service journalctl -u mytask.service --since "7 days ago" --no-pager | grep -icE "Failed|error"
- Как исправить
- Следите за состоянием службы, а не таймера. Проверка «таймер активен» ничего не говорит о том, выполняется ли работа.
- Почему происходит
- Без указания действия при отказе провал задания остаётся только в журнале, а журнал никто не читает по расписанию.
- Как проверить
-
Посмотрите настройку действия при отказе.
systemctl show mytask.service -p OnFailure -p OnFailureJobMode
- Как исправить
-
Добавьте оповещение при отказе отдельной службой. Это единственный способ узнать о провале задания без внешнего наблюдения.
[Unit] OnFailure=notify-failure@%n.service
- Почему происходит
- Если прошлый запуск ещё идёт, новое срабатывание не запускает второй экземпляр, а ставит задачу в очередь. При регулярном превышении времени очередь растёт.
- Как проверить
-
Посмотрите длительность запусков и период таймера.
systemctl show mytask.service -p ExecMainStartTimestamp -p ExecMainExitTimestamp systemctl list-timers mytask.timer --no-pager
- Как исправить
- Увеличьте период или сократите работу задания. Задание, не успевающее в свой период, всегда приводит к неожиданному поведению.
Пример вывода
Таймер работоспособен, задание падает каждый раз. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
$ systemctl is-active mytask.timer
active
$ journalctl -u mytask.service --since "3 days ago" --no-pager | grep -c "Failed with result"
3
systemd[1]: mytask.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: mytask.service: Failed with result 'exit-code'.Связанные ошибки
- Таймер срабатывает, но задача падает незаметно Таймер работает исправно, а задача каждый раз завершается ошибкой, и об этом никто не узнаёт. Как настроить оповещение через OnFailure.
- Резервное копирование не идёт: хранилище копий заблокировано Задача копирования падает на блокировке: прошлый запуск был прерван и не снял её.
- Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
- Failed to parse calendar expression: ошибка в OnCalendar systemd не разбирает календарное выражение таймера. Правила записи OnCalendar и проверка через systemd-analyze calendar.
- Prometheus не собирает метрики: цель недоступна Цель в состоянии down: служба не слушает нужный адрес, закрыт порт или обрывается по таймауту сбора.
- clocksource: Marking clocksource unstable Ядро переключило источник времени. Службы видят скачки времени, таймеры срабатывают не тогда, когда ожидалось.
- smartd: устройства не найдены, наблюдение за дисками не работает Служба наблюдения за дисками запущена, но ничего не проверяет: устройства не определились или скрыты контроллером.
- status=212/TIMERSLACK в systemd Код 212/TIMERSLACK: не удалось задать допуск таймеров процесса из TimerSlackNSec=. Редкий код.
Источники
-
systemd.timer(5)
Связь таймера и запускаемой службы. -
systemd.unit(5)
OnFailure= и действия при отказе. -
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Проверено на systemd 255: таймер остаётся активным при падающем задании.