Cron: планировщик задач в Linux

Бэкапы, ротация логов, обновление кэша, отправка отчётов — всё это должно происходить само. Cron делает это годами без вашего участия. Разберём синтаксис, покажем рабочие задания и типовые грабли.

Как устроен crontab

Cron — демон, который раз в минуту читает таблицы заданий (crontab) и запускает то, чей момент настал. У каждого пользователя своя таблица, есть и системная в /etc/crontab и /etc/cron.d/. Отдельно лежат готовые каталоги /etc/cron.daily, /etc/cron.hourly и подобные — положенные туда скрипты запускаются автоматически по расписанию, заданному в /etc/crontab.

Демон почти всегда уже установлен и запущен. Убедиться в этом можно так:

systemctl status cron       # Debian/Ubuntu
systemctl status crond      # RHEL/AlmaLinux

Открыть свою таблицу на редактирование, посмотреть её и удалить:

crontab -e      # редактировать
crontab -l      # показать
crontab -r      # удалить (осторожно!)

Для задач от root правьте таблицу root: sudo crontab -e. Не смешивайте пользовательские и системные таблицы — в системной есть дополнительное поле «пользователь».

Синтаксис расписания

Строка задания состоит из пяти полей времени и команды:

# ┌── минута (0-59)
# │ ┌── час (0-23)
# │ │ ┌── день месяца (1-31)
# │ │ │ ┌── месяц (1-12)
# │ │ │ │ ┌── день недели (0-7, 0 и 7 = вс)
# * * * * * команда

Символы: * — любое значение, , — перечисление, - — диапазон, / — шаг.

*/15 * * * *   каждые 15 минут
0 3 * * *      каждый день в 03:00
0 */6 * * *    каждые 6 часов
30 2 * * 1     по понедельникам в 02:30
0 0 1 * *      1-го числа каждого месяца

Обратите внимание на день недели и день месяца: если заданы оба поля, cron запустит задачу при совпадении ЛЮБОГО из них, а не обоих сразу. Это классический источник путаницы. Пока не привыкнете к синтаксису, проверяйте выражения в онлайн-парсерах crontab или командой ниже, которая покажет ближайшие срабатывания без реального запуска.

Живой пример реальных задач: ротация nginx-логов ночью, ежечасный сброс кэша приложения и еженедельная выгрузка отчёта на почту — всё это укладывается в три строки crontab.

Спецстроки и переменные окружения

Вместо пяти звёзд можно писать удобные псевдонимы:

@reboot   команда   # при старте системы
@daily    команда   # раз в сутки (полночь)
@hourly   команда   # раз в час
@weekly   команда   # раз в неделю

Cron запускается с урезанным окружением: PATH почти пустой, поэтому указывайте абсолютные пути к бинарникам или задайте переменные в начале crontab:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=admin@example.com

0 4 * * * /usr/local/bin/backup.sh

Логирование и отладка

Cron по умолчанию шлёт вывод задания письмом на локального пользователя. Практичнее писать в файл и добавлять метку времени:

0 4 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Проверить, что cron вообще отработал, можно в системном журнале:

grep CRON /var/log/syslog | tail -n 20
journalctl -u cron --since "1 hour ago"

Если задание не запускается — временно поставьте его на * * * * * и следите за логом: так вы за минуту увидите ошибку вместо ожидания сутки.

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

*/5 * * * * /usr/bin/flock -n /tmp/sync.lock /usr/local/bin/sync.sh

Cron vs systemd timers

На современных дистрибутивах есть альтернатива — systemd timers. Они дают точное логирование через journalctl, зависимости и запуск пропущенных задач (Persistent=true).

systemctl list-timers --all

Для простых периодических задач cron удобнее и понятнее. Для сложных сценариев с зависимостями берите timers. На быстрых NVMe-серверах MAATRIX бэкап-скрипт по крону отрабатывает за секунды и не мешает боевой нагрузке.

Частые вопросы