Что такое systemd timer и как он работает

Что проверяют

Умеете ли вы обслуживать регулярные задачи штатными средствами системы, а не одной строкой в crontab. Заодно проверяют понимание связки из двух юнитов: расписание и работа описываются раздельно.

Как отвечать

Таймер это юнит с расширением .timer, который по расписанию запускает одноимённый юнит .service, либо тот, что указан в Unit=. Работа живёт в сервисе, расписание в таймере.

# backup.timer
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
RandomizedDelaySec=300
AccuracySec=1s

[Install]
WantedBy=timers.target

Сервис делают с Type=oneshot, включают только таймер: systemctl enable --now backup.timer. Смотрят через systemctl list-timers, а вывод самой задачи через журнал её сервиса. Календарное выражение стоит прогнать командой systemd-analyze calendar до включения.

Что даёт настройка: Persistent догоняет пропущенный запуск после простоя машины, RandomizedDelaySec разводит одновременные задачи на парке серверов, монотонные триггеры OnBootSec и OnUnitActiveSec отсчитывают от загрузки и от прошлого запуска. Против cron выигрыш в едином журнале, лимитах через cgroup, зависимостях между юнитами, реакции на сбой через OnFailure= и в том, что второй экземпляр не стартует, пока работает первый.

Где спотыкаются

Запускают таймер через start и забывают enable: после перезагрузки задачи нет. Обратная ошибка не реже: включают сам сервис, и он отрабатывает при загрузке вместо расписания.

Ждут срабатывания секунда в секунду. По умолчанию точность до минуты, задача едет, и это лечится параметром AccuracySec, а не поиском несуществующей ошибки.

Переносят строку из crontab целиком. В юните нет оболочки: конвейеры, перенаправления и подстановки не раскрываются, окружение минимально. Нужны полные пути, отдельный скрипт вместо цепочки команд и переменные через Environment или EnvironmentFile.