Systemd timer: замена cron для периодических задач

Периодические задачи на сервере часто вешают на cron. На системе с systemd можно использовать таймеры: те же unit-файлы, единые логи в journald и календарные расписания. Проблема: как описать задачу в виде service + timer и чем timer лучше или хуже cron. Ниже — пара .service и .timer, включение и проверка.

Решение

1. Service unit — что запускать (одна задача).

[Unit]
Description=Daily backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
User=backup

• Type=oneshot — задача выполняется один раз и завершается; для таймера это типичный вариант.
• ExecStart — скрипт или команда; полный путь.

Сохранить в /etc/systemd/system/backup.service.

2. Timer unit — когда запускать.

[Unit]
Description=Run backup daily at 02:00

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

[Install]
WantedBy=timers.target

• OnCalendar=-- 02:00:00* — каждый день в 02:00 (год-месяц-день, см. man systemd.time).
• Persistent=true — если сервер был выключен в 02:00, выполнить при следующем старте.
• Другие примеры: OnCalendar=Mon..Fri 09:00 (будни 09:00), OnUnitActiveSec=1h (каждый час после последнего запуска).

Сохранить в /etc/systemd/system/backup.timer. Имя таймера должно совпадать с именем service (backup.timer → backup.service).

3. Включение и проверка

sudo systemctl daemon-reload
sudo systemctl enable backup.timer
sudo systemctl start backup.timer
systemctl list-timers --all

Запуск вручную (для проверки): sudo systemctl start backup.service.

Проверка логов

journalctl -u backup.service -n 50
journalctl -u backup.timer -n 20

Timer vs cron

Параметр	systemd timer	cron
Логи	journalctl	отдельные логи/почта
Календарь	OnCalendar (гибко)	crontab-формат
Зависимости	After=, Requires=	нет
Пропуск при downtime	Persistent=true	зависит от реализации

Связанные сниппеты: Systemd: создание unit-файла сервиса, Настройка WP-Cron через crontab. Подробнее про крон и автоматизацию: Бэкенд крон: Битрикс агенты.