В двух словах
Много лет Cron оставался классическим средством автоматизации задач в Unix-системах — надёжным, привычным, проверенным временем. Но технологии не стоят на месте: сегодня ему на смену пришли более умные инструменты. Всё чаще я слышу советы перейти на systemd-таймеры — и у них действительно есть явные преимущества перед старым добрым Cron.
Cron против systemd-таймеров: не пора ли сказать Cron «прощай»?
Cron появился ещё в самом начале эры Unix и до сих пор не теряет своих позиций — это подтверждают и графики Google Trends. Для большинства пользователей привычнее всего запускать задачи через Cron — просто, стабильно, понятно.
Я сам применял Cron для автоматического бэкапа, очистки кэша браузера при выходе, удаления старых журналов — да у каждого есть свои хитрые задачки. Но за всё время работы с ним мне всё чаще стали мешать его ограничения. Здесь на сцену выходят systemd-таймеры — они появились в 2014 году и на практике оказались не просто альтернативой, а настоящим апгрейдом. Всё, что умел Cron, таймеры тоже могут — плюс дают намного больше контроля и удобства. Вот короткое сравнение:
Задания Cron
Таймеры systemd
Если в нужный момент компьютер спит или выключен, задача просто не сработает. К примеру, если скрипт должен был запуститься ночью, но ПК был выключен — задание будет пропущено.
Systemd-таймеры умеют «догонять»: если в расписанное время компьютер был недоступен, нужный скрипт автоматически запустится при включении машины.
Cron работает только по времени — задачи стартуют строго по заданному расписанию (например, в 10:00 или 23:00).
Systemd-таймеры могут запускать задачи не только с отсчётом времени, но и по событиям: например, через минуту после загрузки системы или при завершении другой службы.
Cron абсолютно не заботится о зависимостях: он не проверяет, запущены ли нужные сервисы или находится ли система в нужном состоянии.
Systemd тесно интегрирован с системой, и таймеры могут учитывать состояние служб и их порядок запуска — это даёт огромную гибкость.
Логи Cron очень скудные: по умолчанию всё уходит в /var/log/syslog, а если нужны подробности — всё приходится настраивать вручную.
С журналом systemd вы моментально видите всё: когда задача стартовала, когда закончилась, сколько заняла времени — и всё это в одном месте.
Даже если вы старый поклонник Cron, отрицать очевидное сложно: systemd-таймеры дают гораздо больше гибкости, надёжности и прозрачности для автоматизации задач в Linux.
Три способа запускать скрипты с таймерами systemd на Ubuntu
Я собрал три удобных способа запуска и планирования скриптов через systemd-таймеры:
Быстрый разовый запуск скрипта через systemd-run
Создайте файл ~/resource_snapshot.sh, вставьте в него свой скрипт с помощью nano или любого другого редактора и не забудьте дать права на выполнение с помощью chmod.
Обязательно укажите shebang (#!/bin/bash) и сделайте файл исполняемым командой chmod x — иначе systemd просто не запустит скрипт.
Теперь скрипт можно стартовать через systemd-run как временную службу — идеально для разовых запусков без расписания. После выполнения результат можно посмотреть только через журнал (journalctl), ведь такая служба сразу исчезает из системы.
Классическое расписание скриптов с помощью OnCalendar
OnCalendar — самый привычный способ автоматизации в стиле Cron, но через systemd. Сначала создайте unit-файл службы systemd в nano и впишите нужные параметры: команду запуска (ExecStart), при необходимости — измените путь скрипта. Вы сами выбираете режим работы (simple, exec, idle) — зависит от вашей задачи.
Затем создайте unit-файл таймера: в нём задайте конкретное время или расписание запуска сервиса. Чтобы автозапуск работал ежедневно в 15:00, укажите нужный формат времени по шаблону * *-*-* *:*:*. Структура записи — ДеньНедели-Год-Месяц-День Часы:Минуты:Секунды, звёздочки означают любой вариант. Проверьте синтаксис через systemd-analyze calendar — это поможет избежать ошибок в расписаниях.
Сохраните изменения, перезагрузите systemd, чтобы он подхватил новые unit-файлы. После этого — активируйте таймер, включите автозапуск при старте системы, проверьте работоспособность и наблюдайте детали через journalctl.
Запуск скриптов по событиям и относительным триггерам
Ещё этот способ называют «монотонным паттерном»: тут задания стартуют не по расписанию, а после нужного события — вариант «если X, то Y». Например: чтобы анализировать ресурсы через минуту после загрузки системы, просто прописываю соответствующий параметр в новом unit-файле таймера. При этом сам unit службы может остаться прежним.
Сохраняем таймер, перезапускаем systemd, активируем таймер — и проверяем работоспособность.
Кроме OnBootSec, есть и другие относительные параметры: OnStartupSec, OnUnitActiveSec, OnUnitInactiveSec — всё зависит от вашего сценария.
Как видите, systemd-таймеры это действительно шаг вперёд: они позволяют управлять задачами намного точнее, надёжнее и гибче, чем привычный Cron. Даже если вы всю жизнь пользовались старой школой, возможно, сейчас самое время попробовать современные инструменты автоматизации.
Если вам понравилась эта статья, подпишитесь, чтобы не пропустить еще много полезных статей!
Премиум подписка — это доступ к эксклюзивным материалам, чтение канала без рекламы, возможность предлагать темы для статей и даже заказывать индивидуальные обзоры/исследования по своим запросам!
Подробнее о том, какие преимущества вы получите с премиум подпиской, можно узнать здесь
Также подписывайтесь на нас в:
- Telegram: https://t.me/gergenshin
- Youtube: https://www.youtube.com/@gergenshin
- Яндекс Дзен: https://dzen.ru/gergen
- Официальный сайт: https://www-genshin.ru
