Таймеры systemd

Юнит таймера управляет юнитом сервиса. По соглашению, foo.timer активирует foo.service. Оба файла лежат в /etc/systemd/system/ для локальных установок или /lib/systemd/system/ для пакетов. Минимальная пара выглядит так:

# /etc/systemd/system/db-backup.service
[Unit]
Description=Database backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-db.sh
# Нет секции [Install] — таймер управляет запуском, а не WantedBy

# /etc/systemd/system/db-backup.timer
[Unit]
Description=Daily database backup timer

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

Сервис имеет Type=oneshot — он выполняется до завершения и выходит; systemd не ожидает, что он останется живым. Таймер имеет секцию [Install]; сервис — нет. Включить и запустить:

systemctl daemon-reload
systemctl enable --now db-backup.timer

OnCalendar задаёт расписание по настенным часам с выражениями календарных событий. Синтаксис более читаемый, чем пять полей cron, и systemd его валидирует:

# Проверить выражение календаря до деплоя:
systemd-analyze calendar 'Mon-Fri *-*-* 08:00:00'
# Output: Next elapse: Mon 2024-03-18 08:00:00 UTC

# Типовые календарные события:
OnCalendar=daily              # то же, что *-*-* 00:00:00
OnCalendar=weekly             # Mon *-*-* 00:00:00
OnCalendar=monthly            # *-*-01 00:00:00
OnCalendar=*-*-* 02:30:00     # каждый день в 02:30
OnCalendar=Mon-Fri *-*-* 09:00:00   # по будням в 09:00
OnCalendar=*:0/15             # каждые 15 минут
OnCalendar=*-*-* *:00:00      # в начале каждого часа

systemd-analyze calendar незаменима: вставь любое выражение — она покажет следующие пять активаций. Делай это до включения таймера: поймать неверное выражение до того, как оно пропустит еженедельный запуск, экономит неделю ожидания.

Монотонные таймеры измеряют прошедшее время, а не время по часам. Они отсчитываются от загрузки или от последней активации:

[Timer]
# Сработать через 5 минут после загрузки системы — полезно для пост-загрузочной настройки:
OnBootSec=5min

# Сработать через 1 час после последнего завершения этого сервиса:
OnUnitActiveSec=1h

# Комбинация: через 10 минут после загрузки, затем каждый час:
OnBootSec=10min
OnUnitActiveSec=1h

Ключевое отличие от OnCalendar: монотонные таймеры не выравниваются по границам настенного времени. Если сервис занимает 20 минут, а OnUnitActiveSec=1h, следующая активация — через 1 час после завершения сервиса, а не в начале часа. Это намеренно для задач, которые не должны перекрываться, и где точное время не важно.

# Принимаемые единицы времени:
# 5min, 1h, 30s, 2d, 1week

Persistent=true наверстывает пропущенный запуск OnCalendar. Без этого, если машина была выключена в момент срабатывания таймера, запуск пропускается до следующего запланированного времени. С Persistent=true systemd запускает сервис сразу после следующей загрузки, если последняя активация старше запланированного интервала:

[Timer]
OnCalendar=daily
Persistent=true
# Если машина была выключена в полночь, запустит резервное копирование вскоре после загрузки

Это аналог anacron в systemd для систем, которые не всегда включены. Включай для любой задачи, где «я перезагружался в нужное время» — недопустимое оправдание пропущенного бэкапа, то есть почти всегда.

systemctl list-timers показывает все активные таймеры и время следующей активации. Это первое, что проверяют, когда таймер не работает:

# Список всех активных таймеров:
systemctl list-timers
# NEXT                         LEFT          LAST                         PASSED   UNIT                         ACTIVATES
# Mon 2024-03-18 02:30:00 UTC  14h left      Sun 2024-03-17 02:30:01 UTC  9h ago   db-backup.timer              db-backup.service
# Mon 2024-03-18 09:00:00 UTC  21h left      Sun 2024-03-17 09:00:00 UTC  3h ago   apt-daily.timer              apt-daily.service

# Полный статус конкретного таймера:
systemctl status db-backup.timer

# Последний запуск активируемого сервиса:
systemctl status db-backup.service
journalctl -u db-backup.service -b --since "yesterday"

Столбец LAST показывает, когда последний раз срабатывал; PASSED — как давно. Пустой LAST означает, что никогда не запускался — либо только что запустили, либо Persistent=true ещё не сработал для наверстывания.