Расписания: cron и crontab

Зачем расписания

Бэкап ночью, очистка временных файлов раз в час, отправка отчёта по понедельникам — это задачи, которые должны запускаться сами по времени. Классический инструмент для этого — cron. Это демон, который читает расписания и запускает команды в нужные моменты.

Расписания пользователя хранятся в его crontab. Редактируется он командой:

crontab -e      # открыть свой crontab в редакторе
crontab -l      # показать текущие задачи

Формат: пять полей времени

Строка crontab — это пять полей времени и команда:

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

Примеры:

0 3 * * *        /usr/local/bin/backup.sh      # каждый день в 03:00
*/15 * * * *     /usr/local/bin/check.sh        # каждые 15 минут
0 9 * * 1        /usr/local/bin/report.sh       # по понедельникам в 09:00
0 0 1 * *        /usr/local/bin/monthly.sh      # 1-го числа в полночь

* значит «любое значение», */15 — «каждые 15», список через запятую (0,30) — «в 0 и 30 минут».

Частые грабли

Cron запускается в урезанном окружении: PATH короткий, переменных твоего шелла нет. Скрипт, который работает в терминале, в cron падает, потому что не находит команду или переменную. Поэтому в cron-задачах:

• пишут полные пути к бинарникам (/usr/local/bin/tool, не tool),
• задают нужные переменные прямо в crontab или внутри скрипта,
• не полагаются на текущую директорию: она не та, что в терминале.

Вторая грабля — вывод. Cron пытается отправить stdout и stderr задачи на локальную почту пользователя, но MTA в системе обычно не настроен, и вывод пропадает. Поэтому его перенаправляют в файл лога:

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

>> файл 2>&1 дописывает и обычный вывод, и ошибки в лог. Без этого непонятно, отработала задача или упала.

systemd timers как альтернатива

На systemd-хостах ту же роль играют systemd timers: юнит .timer запускает юнит .service по расписанию. Они логируются в journald (а не теряют вывод), переживают пропущенные запуски и видны через systemctl. cron проще и есть везде; timers мощнее и интегрированы с systemd.

Что важно запомнить

cron запускает команды по расписанию из пяти полей (минута, час, день месяца, месяц, день недели). Редактируется через crontab -e.

Cron работает в урезанном окружении: пиши полные пути и не полагайся на переменные шелла. Вывод перенаправляй в лог через >> файл 2>&1, иначе он теряется.

На systemd-хостах альтернатива — systemd timers: логируются в journald и видны через systemctl.

В следующем уроке разберём переменные окружения, которых cron-задачам как раз часто не хватает.