Systemd timer: время выходить из пещеры

Я ощущаю себя пещерным человеком.

Мне уже много лет, и есть вещи, к которым я привык настолько, что воспринимаю их как константу. Они всегда на своих местах. Они всегда работают. Я никогда не задумываюсь, есть ли что-то еще — потому что зачем, если и так все хорошо?

Когда мне нужно запускать что-то регулярно, с заданной периодичностью — я использую cron. Я не знаю, сколько лет этой утилите. Мне кажется, она была всегда. Открыл crontab -e, написал расписание, забыл. Работает.

Но сегодня, решая очередную задачу с периодическим запуском, я с удивлением узнал, что альтернатива существует. Причем довольно давно.

Systemd timer — это механизм планирования задач, встроенный в systemd. Он решает те же задачи, что и cron, но с бо́льшей точностью и бо́льшим количеством опций:

• Гранулярность до секунд. У cron минимальный интервал — одна минута. У systemd timer такого ограничения нет.
• Защита от дублирования. Если предыдущий запуск еще не завершился — новый не запустится. Cron этого не контролирует: если скрипт работает дольше интервала, запустится второй экземпляр поверх первого.
• Логирование через journalctl. Все запуски, выводы, ошибки — в одном месте. Не нужно вручную перенаправлять stdout в файл.
• RandomizedDelaySec. Случайное смещение времени запуска. Задача стартует не ровно по расписанию, а в случайный момент внутри заданного окна. Это усложняет выявление паттерна по времени — полезно, когда предсказуемость запуска нежелательна.
• Зависимости. Можно указать, что задача должна запускаться только после поднятия сети, после запуска другого сервиса, после монтирования диска. Cron просто стреляет по расписанию, не глядя на состояние системы (или надо лопатить свои костыли).
• Persistent. Если система была выключена в момент запланированного пуска — задача выполнится сразу после загрузки. Cron же пропущенные запуски просто теряет.

Совсем недавно мне нужно было настроить автоматическую ротацию случайно генерируемых gRPC-путей между нодами. Для этого можно было бы использовать cron. Но…наверное, пора выходить из пещеры.

Теперь, когда я знаю про systemd timer, в планах:

• Настроить мониторинг через journalctl — алерты при ошибках ротации, агрегация логов.
• Тонко настроить случайный сдвиг — чтобы еще сильнее затруднить статистический анализ времени ротации системами обнаружения.
• Зависимость от сети — не пытаться ротировать, если сеть еще не поднялась после перезагрузки.
• И, возможно, еще что-то, что умеет systemd timer и не умеет cron. Подозреваю, я пока узнал далеко не все.