Планировщик cron в Linux: как устроен запуск задач

Cron может запускать одну и ту же команду каждые пять минут — и при этом молча не выполнить её, если в расписании указан неверный путь или сервер был выключен в нужную минуту. Ниже — разбор классического cron на примере Cronie 1.6.1: что именно делает планировщик, как читать расписание и где искать причину сбоя.

Что такое cron и где он работает

Cron — это не команда, которая «ждёт» внутри вашего скрипта. Это фоновая служба: она читает расписания и в нужное время запускает новые процессы. В распространённых системах служба называется cron или crond. Точное имя зависит от дистрибутива и пакета.

Этот разбор посвящён классическому синтаксису crontab, знакомому пользователям Cronie 1.6.1 и совместимых реализаций. В Debian и Ubuntu может использоваться другой пакет cron; детали, например поддерживаемые расширения и формат журналов, сверяйте с документацией установленной версии. Cron не равен таймерам systemd: у них другие возможности и правила настройки.

Расписание говорит cron, когда попробовать запустить процесс. Оно не гарантирует, что команда завершится успешно, и не хранит очередь пропущенных запусков.

Как читать расписание

В пользовательском файле crontab каждая задача обычно занимает одну строку. До команды идут пять полей времени: минута, час, день месяца, месяц и день недели. Звёздочка означает «любое допустимое значение».

В полях можно использовать списки, диапазоны и шаг: например, 1,15, 1-5 и */10. Последнее означает каждую десятую минуту в пределах поля, а не «через десять минут после завершения команды».

Например, строка ниже запускает команду в 03:30 каждый день:

30 3 * * * /полный/путь/к/команде

Если ограничены одновременно день месяца и день недели, во многих классических реализациях достаточно совпадения одного из этих полей. Поэтому расписание 0 9 1 * 1 не означает «в понедельник первого числа»: оно может сработать и первого числа, и по понедельникам. Для сложных календарных правил проверьте поведение конкретной версии или используйте отдельный календарный планировщик.

Пользовательское расписание и системные задания

Команда crontab -e открывает расписание текущего пользователя, а crontab -l показывает сохранённые строки. В таком файле в конце задачи указывают команду, но не имя пользователя: cron и так запускает её от владельца этого расписания.

Системные расписания устроены иначе. В файлах вроде /etc/crontab и файлах каталога /etc/cron.d между пятью временными полями и командой добавляют имя пользователя. Не копируйте строку из системного файла в crontab -e без проверки: лишнее поле превратится в часть команды.

Термин — crontab. Это таблица расписания задач cron. Словом называют и сам файл с задачами, и команду управления им.

Первая проверка без сложного скрипта

Чтобы проверить, что задача вообще запускается, можно временно добавить в пользовательский crontab запись, которая раз в пять минут дописывает дату в файл. Путь к date проверьте командой command -v date: в примере используется распространённый путь /usr/bin/date.

*/5 * * * * /usr/bin/date >> /tmp/cron-check.log 2>&1

Откройте расписание командой crontab -e, добавьте строку и сохраните файл. Проверка сохранения — crontab -l: запись должна появиться в выводе. Через пять минут проверьте /tmp/cron-check.log. Если файл пополняется, задача запускается; это ещё не доказывает, что ваш основной скрипт работает правильно. После проверки удалите временную запись.

Почему команда из терминала не работает по расписанию

В интерактивном терминале оболочка получает настройки профиля, текущую папку и привычный набор переменных. Cron обычно запускает команду с более ограниченным окружением. Отсюда три частых расхождения:

• Относительный путь. Команда вроде python script.py может искать файл не там, где вы ожидаете. Укажите абсолютные пути к интерпретатору, скрипту и нужным файлам.
• Другая переменная PATH. Команда, доступная из терминала, может не находиться в окружении cron. Укажите полный путь к исполняемому файлу или задайте нужный PATH в crontab.
• Нет вывода и ошибки остаются незамеченными. Направьте стандартный вывод и поток ошибок в журнал или файл. Не оставляйте диагностику только на почте: её доставка зависит от настроек системы.

Ещё одна ловушка — символ процента (%) в команде: в классическом crontab он имеет специальное значение и может разделить команду и данные для стандартного ввода. Если такой символ нужен, проверьте правила экранирования в документации своей реализации. Для логирования времени обычно проще передавать аргументы скрипту или писать журнал внутри самого приложения.

Что ломается первым и как проверить

Сбой расписания обычно не выглядит как авария: cron не обязан показывать окно или отправлять уведомление на экран. Проверяйте цепочку по порядку — сохранена ли запись, работает ли служба, запускается ли исполняемый файл, может ли пользователь писать в нужный каталог.

• Задача не запускается вообще. Проверьте вывод crontab -l и состояние службы. В зависимости от дистрибутива ищите службу с именем cron или crond; журналы смотрите через системный журнал либо журналы cron, предусмотренные вашей системой.
• Появляется “command not found”. Найдите полный путь к программе командой command -v имя_программы и укажите его в расписании.
• Появляется “Permission denied”. Убедитесь, что у пользователя есть право запускать файл и доступ к каждому каталогу по пути. Проверять нужно именно от имени владельца crontab.
• Задача стартует дважды или накладывается сама на себя. Cron не ждёт завершения предыдущего запуска перед следующим по расписанию. Если задача может выполняться дольше интервала, добавьте защиту от параллельного запуска на уровне приложения или операционной системы.
• После перезагрузки пропущенный запуск не появился. Это ожидаемо для обычного cron: он не обязан догонять пропущенные задания. Если выполнение после простоя критично, изучите anacron или таймеры systemd — это отдельные механизмы со своими ограничениями.

Границы cron: календарь, время и надёжность

Классический cron подходит для повторяющихся задач с расписанием по календарному времени: очистки временных файлов, периодического отчёта или простого резервного копирования. Но расписание по минутам не задаёт длительность выполнения, повтор после ошибки или гарантию «ровно один раз».

Переход на летнее или зимнее время, изменение часового пояса и перезапуск службы могут влиять на то, когда сработает календарная задача. Точное поведение зависит от реализации и настроек системы. Если важна точность для конкретного часового пояса или даты, не полагайтесь на предположение: проверьте документацию своей версии и испытайте расписание на тестовой системе.

Без замеров нельзя утверждать, что cron подходит для любого объёма работы. За неделю сравните плановое и фактическое время запуска, длительность выполнения, код завершения и число параллельных процессов. Если задачи начинают пересекаться или пропуски стоят дорого, перенос расписания в очередь задач или систему с контролем повторов может оказаться безопаснее.

Что делать дальше

Начните с одной тестовой записи и подтвердите четыре вещи: cron её сохранил, служба работает, команда запускается от нужного пользователя, результат попадает в журнал. Затем настройте логирование и контроль кода завершения основного скрипта. Если требуется догонять пропущенные задания, гарантировать выполнение или управлять зависимостями между задачами, выбирайте отдельный инструмент, а не усложняйте расписание cron.