Cron systemd timers – це два базові підходи до планування задач у Linux. Якщо потрібен швидкий запуск простого скрипта за розкладом, cron часто достатній. Якщо важливі залежності, контроль середовища, логування через journal і запуск після пропущеного вікна, краще переходити на systemd timers.
У homelab різниця проявляється швидко. Нічний backup, оновлення контейнерів, перевірка стану дисків або синхронізація з віддаленим вузлом можуть виглядати як звичайний cron job. Проблеми починаються тоді, коли задача залежить від мережі, змонтованого сховища, VPN-тунелю або конкретного сервісу.
Нижче – практичний розбір без романтизації. Де cron ще нормальний варіант, де він уже заважає, і чому systemd timers у домашній інфраструктурі часто дають менше сюрпризів після ребута.
Коли обирати cron, а коли systemd timers
Якщо задача примітивна, самодостатня і не потребує контексту, cron залишається робочим інструментом. Якщо задача має життєвий цикл сервісу, залежності або потребує передбачуваного запуску після простою, cron systemd timers вже не рівні – systemd тут сильніший.
| Критерій | cron | systemd timers |
|---|---|---|
| Простий періодичний запуск | Так | Так |
| Залежність від network-online або mount | Слабко | Нормально вирішується |
| Логування | Потрібно доробляти вручну | Через journal |
| Пропущений запуск після вимкнення вузла | Зазвичай губиться | Може бути відпрацьований пізніше |
| Окреме середовище виконання | Обмежено | Краще контролюється |
| Прив’язка до unit-сервісів | Ні | Так |
Практичне правило просте. Для одного-двох незалежних скриптів cron не створює проблем. Коли задачі починають чіплятись за інфраструктуру, розклад уже не головне. Головне – що саме доступне в момент запуску.
Тут і з’являється нетривіальна межа. Багато cron jobs виглядають стабільними місяцями, а ламаються тільки після першого незапланованого ребута або довгого простою. У systemd timers така деградація рідша, бо таймер працює разом із моделлю сервісів, а не окремо від неї.
Де cron ще достатній і не вимагає міграції
Cron підходить для коротких локальних задач без залежностей. Наприклад, чистка тимчасових файлів, ротація власного каталогу з dump-файлами, локальний export статистики або періодичний запуск скрипта, який не залежить від мережі.
Його головний плюс – швидкість. Один запис у crontab, один shell-скрипт, мінімум рухомих частин. Для невеликого хоста, де немає складного boot-порядку, цього достатньо.
Але навіть тут є типова пастка. Cron запускає задачу в бідному середовищі. PATH, shell, змінні середовища і робочий каталог можуть відрізнятись від ручного запуску. Через це скрипт, який працює в інтерактивній сесії, у cron падає без очевидної причини. На невеликій кількості jobs це терпимо. Після десятка записів у crontab пошук таких дрібниць стає втомливим.
Якщо cron вже використовується, мінімальна гігієна така:
SHELL=/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin MAILTO="" 15 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
Це не робить cron сучаснішим. Просто зменшує кількість безглуздих падінь через оточення.
Чому systemd timers кращі для серверних задач
Systemd timers виграють там, де задача є частиною системи, а не просто командою за розкладом. Вони запускають не абстрактний shell-фрагмент, а service unit. Через це простіше описати залежності, обмеження, порядок старту і спосіб перевірки.
Для homelab це особливо корисно в трьох сценаріях. Перший – jobs, що чекають мережу або VPN. Другий – задачі, які треба запускати після монтування NAS або зовнішнього диска. Третій – операції, де потрібен зрозумілий аудит: коли саме сервіс стартував, чому завершився і який код повернув.
Ще одна сильна сторона – логування через systemd. Не треба окремо вигадувати редіректи, лог-файли і ротацію на кожну дрібну job. Для більшості адміністративних задач достатньо journal, особливо якщо важливий не архів на роки, а швидка діагностика з нормальним контекстом.
Найкорисніша деталь, яку часто недооцінюють: systemd timers краще переживають нерегулярний uptime. Для домашнього сервера, який інколи вимикається, це не косметика. Backup, який мав виконатися вночі, але вузол був відключений, часто важливіший за «ідеально красивий» розклад.
Як налаштувати systemd timers для щоденного backup
Для переходу з cron на systemd timers потрібно створити два unit-файли: service і timer. Service описує, що саме запускати. Timer описує, коли це робити. Такий розподіл зручніший за cron, бо команда і розклад не змішані в одному рядку.
Нижче – базовий приклад щоденного backup-скрипта.
Сервіс
/etc/systemd/system/homelab-backup.service [Unit] Description=Homelab backup job Wants=network-online.target After=network-online.target [Service] Type=oneshot ExecStart=/usr/local/bin/backup.sh
Таймер
/etc/systemd/system/homelab-backup.timer [Unit] Description=Run homelab backup daily [Timer] OnCalendar=*-*-* 03:15:00 Persistent=true [Install] WantedBy=timers.target
Далі достатньо перечитати конфігурацію і ввімкнути таймер.
sudo systemctl daemon-reload sudo systemctl enable --now homelab-backup.timer
Persistent=true – один із найсильніших аргументів за cron systemd timers у домашній інфраструктурі. Якщо вузол був вимкнений у запланований момент, systemd намагатиметься відпрацювати пропущений запуск після повернення системи в online-стан. Для backup, sync і maintenance jobs це часто правильна поведінка.
Як перевірити, що таймер і задача реально працюють
Перевірка для systemd timers прозоріша, ніж у cron. Можна окремо подивитися список таймерів, стан пов’язаного сервісу і журнали виконання. Це швидко показує, чи не впирається задача в порядок старту, права або недоступну мережу.
systemctl list-timers --all systemctl status homelab-backup.timer systemctl status homelab-backup.service journalctl -u homelab-backup.service
Для ручного прогону сервіс можна стартувати окремо, без очікування розкладу.
sudo systemctl start homelab-backup.service
У cron перевірка грубіша. Зазвичай доводиться дивитися syslog, власні лог-файли або додавати тимчасові маркери в shell-скрипт. Це працює, але діагностика виходить розсипаною по системі.
На практиці саме перевірка і розбір падінь часто вирішують вибір. Розклад пишеться один раз. Дебаг відкривається щоразу, коли відвалюється DNS, мережеве сховище або токен доступу.
Де cron і systemd timers зазвичай ламаються
Cron найчастіше падає не через сам розклад, а через оточення. Немає PATH, не той shell, відсутній робочий каталог, інший користувач, недоступна мережа. Проблема в тому, що всі ці збої виглядають однаково нудно: задача просто не зробила те, що мала.
У systemd timers інший набір граблів. Часто забувають, що таймер запускає service unit, а не довільний shell-контекст. Якщо в скрипті використовується щось із профілю користувача, воно не з’явиться автоматично. Друга типова помилка – неправильна модель залежностей. Наприклад, After=network-online.target не гарантує, що віддалений API або NAS вже реально доступний. Це лише означає, що systemd вважає мережевий стек піднятим.
Тут є межа, яку документація рідко проговорює прямо. Якщо задача чутлива до зовнішньої доступності сервісу, самих unit-залежностей мало. Потрібна окрема перевірка в скрипті: ping до хоста, перевірка mountpoint, тест сокета або retry-логіка. Інакше навіть акуратний systemd timer просто падатиме більш структуровано, але не розв’яже саму проблему.
Що обрати для homelab, self-hosted і невеликих серверів
Вибір між cron systemd timers залежить не від моди, а від типу задачі. Для одиничних локальних jobs cron все ще нормальний. Для backup, sync, health checks, cleanup контейнерів і будь-яких дій із залежністю від стану системи краще одразу брати systemd timers.
Є й чисто операційний аргумент. Коли на вузлі з’являється 8-10 запланованих задач, cron починає розповзатися по root crontab, user crontab, shell-скриптах і випадкових логах. Systemd тримає це зібраніше: є service, є timer, є журнал, є status. Це не робить систему простішою в абсолюті, але робить її менш хаотичною.
Для контейнерного хоста теж варто не плутати рівні. Якщо задача стосується самого сервера – backup volumes, prune образів, перевірка диска, синхронізація snapshot – планувати її краще на хості через systemd timers. Якщо ж це внутрішня логіка застосунку, розклад має жити всередині застосунку або в окремому worker-сервісі, а не в root crontab хоста.
Підсумок короткий. Cron підходить для простих jobs, які не страшно втратити або повторити вручну. Systemd timers краще там, де задача вже стала частиною інфраструктури. У homelab цей момент настає раніше, ніж здається.