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

Таймер срабатывает, но задача падает незаметно

Таймер сообщает только о срабатывании: успешность задачи его не касается. Задача может падать неделями, а в списке таймеров всё будет выглядеть нормально. Это одна из самых неприятных ситуаций: резервное копирование «работает», пока не понадобится восстановление.

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

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

Неудачи задачи никто не отслеживает

Состояние failed у одноразовой службы не мешает таймеру срабатывать дальше. В списке таймеров и в состоянии таймера ошибок не видно.
Задача завершается с нулём, ничего не сделав

Скрипт без проверки ошибок возвращает ноль даже при неудаче внутри. Тогда даже проверка состояния ничего не покажет.
Ошибки не попадают в журнал

Если вывод задачи перенаправлен в файл или подавлен, ошибки не видны ни в journalctl, ни в состоянии.

Диагностика

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

Все упавшие unit. Регулярный просмотр этой команды закрывает большую часть незамеченных сбоев.

systemctl --failed --no-pager

История запусков задачи за неделю: видно, каждый раз она падает или изредка.

journalctl -u myapp.service --since "7 days ago" --no-pager | tail -40

Итог последнего запуска в числах.

systemctl show myapp.service -p ExecMainStatus -p Result -p NRestarts

Решение

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

1. Неудачи задачи никто не отслеживает

Почему происходит: Состояние failed у одноразовой службы не мешает таймеру срабатывать дальше. В списке таймеров и в состоянии таймера ошибок не видно.

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

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

systemctl status myapp.service --no-pager | head -8
journalctl -u myapp.service --since "7 days ago" --no-pager | grep -iE "failed|error" | tail

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

Добавьте оповещение: unit OnFailure= вызывает вашу службу уведомления при неудаче. Второй слой — регулярная проверка systemctl --failed.

[Unit]
OnFailure=notify-failure@%n.service

2. Задача завершается с нулём, ничего не сделав

Почему происходит: Скрипт без проверки ошибок возвращает ноль даже при неудаче внутри. Тогда даже проверка состояния ничего не покажет.

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

Посмотрите, что задача пишет в журнал, и её код возврата.

journalctl -u myapp.service -n 40 --no-pager
systemctl show myapp.service -p ExecMainStatus

Как исправить: В скриптах включайте прерывание при ошибке (set -euo pipefail) и возвращайте ненулевой код. Без этого таймер и systemd бессильны.

3. Ошибки не попадают в журнал

Почему происходит: Если вывод задачи перенаправлен в файл или подавлен, ошибки не видны ни в journalctl, ни в состоянии.

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

Посмотрите настройки вывода.

systemctl show myapp.service -p StandardOutput -p StandardError

Как исправить: Оставьте вывод в журнале: значение journal по умолчанию как раз для этого. Перенаправление в файл лишает вас истории запусков.

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

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

$ systemctl list-timers --no-pager | grep backup
Tue 2026-09-16 00:00:00 MSK 9h left  Mon 2026-09-15 00:00:11 MSK 15h ago backup.timer backup.service

$ systemctl status backup.service --no-pager | head -6
× backup.service - Nightly backup
     Loaded: loaded (/etc/systemd/system/backup.service; static)
     Active: failed (Result: exit-code) since Mon 2026-09-15 00:00:19 MSK; 15h ago

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

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

Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
Таймер активен, но не срабатывает Таймер systemd в состоянии active, но служба не запускается. Разбор: нет условия срабатывания, таймер не включён, ошибка в OnCalendar.
status=0/SUCCESS, но служба считается упавшей Программа завершилась успешно, а systemctl показывает inactive или failed. Разбор: Type=simple против forking, RemainAfterExit, демонизация.
Пропущенное срабатывание таймера: Persistent и выключенная машина Таймер не выполнил задачу, потому что в момент срабатывания машина была выключена или служба была недоступна. Как работает Persistent=true.
Failed to parse calendar expression: ошибка в OnCalendar systemd не разбирает календарное выражение таймера. Правила записи OnCalendar и проверка через systemd-analyze calendar.
Grafana: расширение не загружается из-за подписи Расширение не появляется в интерфейсе: не подписано или подпись не совпадает. Как разрешить осознанно.
Prometheus: каталог данных занят другим экземпляром Служба не запускается: блокировка каталога данных после аварийного завершения или второй экземпляр.
clocksource: Marking clocksource unstable Ядро переключило источник времени. Службы видят скачки времени, таймеры срабатывают не тогда, когда ожидалось.

Источники

systemd.unit(5)
OnFailure=, OnFailureJobMode= и шаблонные unit уведомлений. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Проверено связкой таймера и падающей задачи: таймер продолжает срабатывать по расписанию. собственная проверка, systemd 255
сверено 15 сентября 2026