Чому systemd-таймери кращі за демон cron

Кожен, хто планує завдання в Linux, тягнеться до cron, і саме слово стало загальною назвою для будь-якого запуску за розкладом. У травні 2026 року автор блогу tjll.net доводить, що в 2026-му буквальний демон cron і його сучасніші родичі — неправильний інструмент, а systemd-таймер заслуговує більше любові, ніж отримує.

Чому не cron

Його заперечення практичні, а не ідеологічні. Неоднозначні налаштування $PATH роблять виконання cron-скриптів важко передбачуваним. stdout і stderr часто зникають у чорній дірі або потрапляють у поштову систему хоста, що рідко кому потрібно. Історію виконань важко відслідковувати й досліджувати. А граматика розкладу, якою дехто пишається, нелегка для читання: вираз `01,31 04,05 1-15 1,6 *` вимагає справжніх зусиль для розшифрування. Таймери, пише він, розв'язують усі ці проблеми й не тільки.

Сервіс, таймер і розклад

systemd-таймер — це тип unit, який планує інший unit, зазвичай сервіс. Приклад у статті — сервіс із шансом один із десяти вимкнути машину, до якого додається файл таймера з тією ж основою назви в /etc/systemd/system, адже типове значення Unit= вибирає відповідний .service. Запуск .timer ставить його на годинник, але не виконує ціль; enable змушує його підніматися при завантаженні через ціль встановлення WantedBy=timers.target. Дві деталі часто збивають з пантелику: ExecStart типово не виконується через shell, тож конвеєри не працюють так, як написано, і він не успадковує змінних середовища понад типові для системного менеджера.

Календарні події та проміжки часу

Найбільший концептуальний стрибок порівняно з cron — два види розкладу в systemd. Перший — звична календарна подія (daily або її повна форма `*-*-* 00:00:00`), другий — проміжок часу, відлічуваний від попередньої події, наприклад OnBootSec=1h разом з OnUnitActiveSec=1h: запуск через годину після завантаження, а далі щогодини після кожного виконання. Друга форма часто відповідає справжньому наміру: завдання, що чистить тимчасовий каталог, мало що виграє від запуску одразу після завантаження, а бот, який опитує API рівно кожні п'ятнадцять хвилин за годинником, створює пік трафіку, якого розклад за проміжком часу уникає. Автор радить починати з довідника systemd.time і команди systemd-analyze calendar, яка перевіряє й пояснює вирази і навіть розшифровує класичні cron-шаблони.

Він окремо називає можливості, яких cron не має: list-timers, що однією таблицею показує, що запуститься наступним і що виконалося останнім; WakeSystem=, який будить призупинену машину для виконання завдання; FixedRandomDelay= і RandomizedOffsetSec=, що розосереджують запуски, аби уникнути піків «стада, що тупотить»; і Persistent=, який виконує пропущений запуск одразу після активації таймера — корисно для перевірок конфігураційного менеджменту на вимкненому ноутбуці. Таймери рівня користувача через systemctl --user так само слушні, хоча ціль встановлення іноді має бути default.target. Годинник усе одно має бути точним, і timedatectl timesync-status показує, чи це так.