Cron в Linux: подробное руководство по планированию задач

Знание cron полезно как обычному пользователю, так и администратору. В этой статье вы найдёте простые объяснения, примеры, готовые шаблоны, чек-листы для ролей, сценарии устранения неисправностей и рекомендации по безопасности. Начнём с базового — потом углубимся.

Основные понятия

• Cron — демон (служба), который периодически проверяет расписания задач и запускает команды в указанное время.
• Crontab — файл с расписанием задач для конкретного пользователя или для системы.
• Cron job (задача cron) — одна строка в crontab, описывающая время и команду.

Короткое определение: crontab — это «календарь задач» для вашего пользователя в Linux.

Почему cron всё ещё важен

Cron прост, надёжен и присутствует практически во всех дистрибутивах Linux. Он хорошо подходит для периодических задач: бэкапов, очистки логов, загрузки данных, отправки отчётов. Для машин, которые работают 24/7, cron остаётся незаменимым инструментом. Однако у cron есть ограничения (нет учёта пропущенных запусков при выключенном ПК), и о них тоже поговорим.

Что такое cron?

Cron — системный сервис, работающий в фоновом режиме. Он читает crontab-файлы и запускает команды в запланированное время. Разные дистрибутивы могут использовать разные реализации (cronie, vixie-cron, fcron и т. п.), но синтаксис crontab у большинства схож.

Эта статья ориентирована на vixie-cron (широко распространён в Ubuntu и её производных), но объяснения применимы ко многим другим версиям.

Что такое crontab?

Crontab — это файл, где указываются задачи. У каждого пользователя свой crontab, включая root. Пользовательские crontабы хранятся в каталоге:

/var/spool/cron/crontabs/

Просмотреть crontab текущего пользователя можно командой:

crontab -l

Чтобы посмотреть crontab root:

sudo crontab -l

Существует и системный crontab:

/etc/crontab

А также каталоги для периодических задач:

/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/
/etc/cron.d/

Как правило, эти системные задания создаются пакетами и редактируются редко.

Как запланировать задачу (базовый сценарий)

Правильный способ редактирования crontab — использовать его интерфейс:

crontab -e

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

sudo crontab -u username -e

Crontab состоит из двух частей:

1. Переменные окружения (PATH, SHELL, HOME и т. п.).
2. Список задач, по одной задаче на строку.

Образец строки задачи (формат):

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

Простой пример запуска скрипта в 3:30 каждое утро:

30 3 * * * /usr/local/bin/backup.sh

Или ежечасный лог-файл:

0 * * * * /usr/local/bin/rotate-logs.sh >> /var/log/myapp/rotate.log 2>&1

Специальные выражения

Вместо пяти полей можно использовать короткие ключи:

• @reboot — при загрузке системы
• @hourly — ежечасно (т.е. 0 )
• @daily — ежедневно (т.е. 0 0 *)
• @weekly — еженедельно (т.е. 0 0 0)
• @monthly — ежемесячно (т.е. 0 0 1 )
• @yearly — ежегодно

Пример:

@reboot /usr/local/bin/start-agent.sh

Шаблоны и шаги

• Звёздочка () означает «каждое значение». Например, в поле минут `` — каждую минуту.
• Диапазон 14-22 в поле часов — каждый час с 14 до 22 (включительно).
• Список 1,3,5 в поле дня недели — понедельник, среда, пятница (если считать 1 — понедельник в вашей системе).
• Шаг */15 в поле минут — каждые 15 минут.
• Комбинации возможны: 3-20/3 — каждые 3 часа в диапазоне с 3 до 20.

Важно: нельзя смешивать текстовые и числовые диапазоны в одном выражении (например, jan-mar допустимо в поле месяц, но Tue,Fri-Sun — недопустимо, если смешивать форматы неправильно).

Полезные примеры crontab

Примеры, которые вы можете вставить прямо в crontab -e.

• Резервное копирование каждое утро в 02:00:

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

• Перезапуск сервиса каждый день в 04:05 (как пример):

5 4 * * * /bin/systemctl restart myservice

• Смена обоев каждые 3 дня в 19:00 (пример для настольного пользователя):

0 19 */3 * * DISPLAY=:0 /usr/local/bin/change-wallpaper.sh

• Проверка подкастов по понедельникам в 10:20 и 20:20:

20 10 * * 1 /usr/local/bin/check-podcasts.sh
20 20 * * 1 /usr/local/bin/check-podcasts.sh

• Напоминание о дне рождения 25 марта каждые 30 минут в интервале 09:00-17:00:

*/30 9-17 25 3 * /usr/local/bin/birthday-reminder.sh

• Проверка почты каждые 15 минут с 8 до 20 по будням:

*/15 8-20 * * 1-5 /usr/local/bin/check-mail.sh >> /home/username/mail-check.log 2>&1

Советы по созданию надёжных задач

1. Всегда указывайте полные пути к исполняемым файлам (например, /usr/bin/python3), либо явно задайте PATH в начале crontab.
2. Перенаправляйте stdout и stderr в лог: >> /var/log/task.log 2>&1.
3. Добавляйте полезные временные метки в логи внутри скриптов: echo "$(date +'%F %T') — started" >> /var/log/task.log.
4. Тестируйте команды вручную от имени пользователя, у которого будет crontab.
5. Не полагайтесь на окружение: crontab запускается в минимальном окружении.
6. Давайте задачам имена/комментарии в отдельной строке, чтобы в будущем легче было читать crontab (комментарии начинаются с #).
7. Оставляйте пустую строку в конце файла — некоторые реализации cron требуют этого.
8. Экранируйте символ % в командах (замените на \%), так как cron интерпретирует % как перевод строки.

Как проверять, что задачи выполняются

1. Логи cron:

• На большинстве систем сообщения cron попадают в системный лог /var/log/syslog или /var/log/cron. Проверка общая команда:

cat /var/log/syslog | grep -i cron

• На некоторых дистрибутивах есть отдельный файл /var/log/cron.

2. Логи задач: если вы перенаправили вывод в файл (>> /path/to/log 2>&1), смотрите этот файл.

3. Email-уведомления: cron может отправлять стандартный вывод и ошибки по почте на локального пользователя. Для этого нужна настроенная MTA (postfix/ssmtp/exim). Многие домашние системы этого не имеют.

4. Проверка статуса службы cron (systemd):

systemctl status cron

(Для систем с Upstart или SysV команды отличаются — service cron status или initctl list.)

Что делать, если cron не работает

Пошаговый план диагностики:

1. Служба запущена?

systemctl status cron
# или
service cron status

Если служба не запущена — стартуйте и посмотрите логи:

sudo systemctl start cron
sudo journalctl -u cron --since "1 hour ago"

2. Есть ли права на crontab?

Проверьте файлы /etc/cron.allow и /etc/cron.deny.

• Если существует cron.allow, в нём должен быть ваш пользователь.
• Если существует cron.deny, в нём не должно быть вашего пользователя.

3. PATH и окружение

Crontab использует минимальный PATH. Либо укажите PATH в начале crontab, либо используйте абсолютные пути:

PATH=/opt/myapp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Или в скрипте:

#!/bin/bash
export PATH=/opt/myapp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# дальше задачи

4. Формат crontab

• Одна задача — одна строка.
• Комментарии начинаются с # и должны быть отдельной строкой.
• Экранируйте %.
• Обязательно пустая строка в конце файла.

5. Проверьте вывод cron в системных логах после попытки запуска.

6. Если задача зависит от GUI (DISPLAY), убедитесь, что у неё установлен нужный DISPLAY и XAUTHORITY, или запустите задачу через systemd пользовательский таймер/сервис.

Встроенные инструменты: GUI и веб-интерфейсы

Не обязательно редактировать crontab в терминале:

• KDE: KCron (Системные настройки → Планировщик задач).
• GNOME: GNOME Schedule (если доступен).
• Веб-интерфейсы: Crontab-UI, Minicron — полезны при управлении задачами на многих машинах.

Альтернативы и дополнения к cron

• at — для одноразовых заданий.
• anacron — дополняет cron: выполняет задания, пропущенные из‑за выключения компьютера (каждое задание — не чаще одного раза в день).
• systemd timers — современная замена/альтернатива: интеграция с systemd, учёт пропущенных запусков и более гибкая конфигурация (хороши для сервисов и серверов с systemd).
• fcron, Hcron, SuperCron — расширенные реализации с дополнительными функциями.
• GNUbatch — ориентирован на зависимости между заданиями.

Краткая рекомендация:

• Серверы 24/7: cron (или systemd timers) подходят отлично.
• Ноутбуки/desktops, которые часто выключают: используйте anacron или systemd timers с опцией Persistent=true.

Сравнение: cron vs anacron vs systemd timers

• cron: запускает по расписанию, не компенсирует пропуски (подходит для серверов).
• anacron: выполняет пропущенные задания при следующем запуске системы; не гарантирует точное время (минимальная единица — день).
• systemd timers: гибкость, опции Persistent и AccuracySec, интеграция с systemd-journal.

Короткая таблица (качественно):

• Надёжность при выключении: cron — низкая, anacron — высокая, systemd timers — высокая (с настройкой).
• Простота: cron — прост, anacron — прост, systemd timers — сложнее в конфигурации.
• Зависимости: cron — нет, anacron — нет, systemd timers — можно через unit-файлы.

Шаблоны и чек-листы (Role-based)

Ниже — наборы задач и контрольных пунктов для разных ролей.

Для администратора системы

Чек-лист при создании периодической задачи:

• Определить цель и ожидаемый результат.
• Выбрать пользователя, от которого должна выполняться задача.
• Указать абсолютные пути ко всем исполняемым файлам.
• Задать PATH или прописать в скрипте.
• Перенаправить stdout/stderr в лог.
• Установить управление ротацией логов (logrotate).
• Добавить мониторинг выполнения (оповещение при ошибках).
• Проверить безопасность (права на скрипты).

Для разработчика

• [ ] Локально выполнить команду в окружении похожем на crontab (например, env -i /bin/bash -l -c 'команда').
• Написать idempotent-скрипты (бесследное повторное выполнение).
• Сделать тестовую задачу с маленьким интервалом, чтобы убедиться в результате.
• Убедиться, что задачи не конкурируют за ресурсы (lock-файл или flock).

Для настольного пользователя

• Оценить, нужна ли задача при выключенном компьютере (если нет — использовать anacron или systemd timer с Persistent).
• Проверить DISPLAY/XAUTHORITY для GUI-скриптов.
• Раз в месяц просматривать crontab на предмет устаревших задач.

Руководство по безопасности и надёжности

• Не храните пароли в crontab.
• Скрипты должны проверять входные данные и окружение.
• Используйте абсолютные пути и минимально допустимые привилегии (не запускайте лишнее от root).
• Ограничьте доступ к crontab и к исполняемым файлам с помощью прав доступа (chmod 700 для приватных скриптов).
• Для предотвращения одновременного запуска нескольких экземпляров используйте flock:

# Пример использования flock
* * * * * /usr/bin/flock -n /var/lock/mytask.lock /usr/local/bin/mytask.sh >> /var/log/mytask.log 2>&1

• Логи храните в контролируемых местах и настраивайте ротацию (например, logrotate).

Типичные ошибки и их исправление

1. Ничего не выполняется: проверьте, запущен ли cron, и нет ли ошибок в crontab.
2. Команда выполняется, но ничего не делает: проблема в PATH; указывайте абсолютные пути.
3. Задача выполняется под неверным пользователем: убедитесь, что редактировали нужный crontab (crontab -e vs sudo crontab -e).
4. Скрипт требует GUI: добавьте переменные DISPLAY и XAUTHORITY.
5. Не видите логов: перенаправьте stdout/stderr и проверьте права на папку логов.

Playbook: как безопасно ввести новую задачу в продакшен

1. Разработать и протестировать скрипт локально.
2. Добавить логирование и возврат кода завершения.
3. Создать тестовую crontab с коротким интервалом (например, каждые 5 минут).
4. Проверить логи и поведение в течение 24–48 часов.
5. Перенести задачу в нужный интервал и документировать её в change-log.
6. Настроить оповещения на ошибку (например, через систему мониторинга или письма).

Incident runbook: задача не выполняется (быстрый план)

1. Проверить статус службы: systemctl status cron.
2. Просмотреть последние строки логов cron: journalctl -u cron --no-pager -n 200 или grep -i cron /var/log/syslog.
3. Проверить crontab на синтаксические ошибки: crontab -l.
4. Выполнить команду вручную под тем же пользователем.
5. Проверить окружение (PATH, SHELL, HOME).
6. Если требуется GUI — проверить DISPLAY и права.
7. Если всё ещё неясно — временно заменить команду тестовой (echo "ok" >> /tmp/cron-test.log) и посмотреть, выполнится ли она.

Тест-кейсы и критерии приёмки

Критерии приёмки новой задачи:

• Задача запускается в запланированное время на тестовой машине в 90% запусков в течение 3 дней.
• Задача записывает лог с отметкой времени при старте и завершении.
• При успешном завершении возвращает код 0, при ошибке — ненулевой код и отправляет уведомление.
• Скрипт не оставляет временных файлов без удаления или ротации.

Пример тест-кейса:

• Подготовка: добавить тестовую задачу */5 * * * * /usr/local/bin/test-script.sh >> /tmp/test.log 2>&1.
• Ожидаемый результат: файл /tmp/test.log пополняется каждые 5 минут, в логе есть отметки времени и код 0.

Шпаргалка (cheat sheet)

• Просмотр crontab: crontab -l
• Редактирование crontab: crontab -e
• Удалить crontab: crontab -r
• Указать crontab для пользователя: sudo crontab -u username -e
• Проверить сервис: systemctl status cron или service cron status
• Проверка логов: grep -i cron /var/log/syslog

Snippets — полезные куски кода

1. Логирование с отметкой времени:

*/10 * * * * /usr/local/bin/task.sh >> /var/log/task.log 2>&1 && echo "$(date +'%F %T') task finished" >> /var/log/task.log

2. Использование flock для одного экземпляра:

0 3 * * * /usr/bin/flock -n /tmp/mytask.lock /usr/local/bin/mytask.sh

3. Переадресация почты cron в файл (если нет MTA):

MAILTO=""
* * * * * /usr/local/bin/check.sh >> /home/username/cron-mail.txt 2>&1

Ментальные модели и эвристики

• “Cron — это таймер, а не очередь задач”: cron запускает задачи в заданные моменты, но не управляет зависимостями.
• “Окружение crontab максимально минимально”: думайте, что crontab — это чистая система без ваших привычных алиасов и переменных.
• “Логи — ваши лучшие друзья”: без логов вы не сможете диагностировать поведение.
• “Разделение обязанностей”: не смешивайте системные задачи и пользовательские скрипты без явной необходимости.

Когда cron не подходит (контрпримеры)

• Если вам нужна гарантия исполнения задания, даже если система была выключена в запланированное время — используйте anacron или systemd timers с Persistent.
• Для сложных зависимостей между задачами лучше подойдёт GNUbatch или система оркестрации (например, airflow для data pipelines).
• Для задач с миллисекундной точностью cron не годится — он не поддерживает секунды.

Совместимость и миграция

• При переходе между реализациями cron проверьте: поддерживает ли новая реализация @reboot, экранирование %, формат cron.d и системный crontab /etc/crontab.
• Перенос crontab между машинами: crontab -l > mycrontab.txt на одной машине и crontab mycrontab.txt на другой. Перед применением проверьте содержимое файла.

Краткий глоссарий (1 строка каждый)

• cron: фонова служба для запуска заданий по расписанию.
• crontab: файл расписания задач для пользователя или системы.
• anacron: утилита, дополняющая cron для выполнения пропущенных заданий.
• systemd timers: таймеры systemd, современная альтернатива cron с доп. возможностями.

Решение-дерево для выбора инструмента (Mermaid)

flowchart TD
  A[Нужно запланировать задачу?] --> B{Запускать регулярно или один раз?}
  B -->|Один раз| C[Используйте at]
  B -->|Регулярно| D{Система всегда онлайн?}
  D -->|Да| E[cron или systemd timers]
  D -->|Нет| F[anacron или systemd timers с Persistent]
  E --> G{Нужна интеграция с unit-файлами?}
  G -->|Да| H[systemd timers]
  G -->|Нет| I[cron]

Практическая методология: «Plan–Test–Deploy–Monitor»

1. Plan — описать задачу, цель и критерии успеха.
2. Test — протестировать локально и в тестовой среде с коротким интервалом.
3. Deploy — выставить в crontab в production, документировать.
4. Monitor — настроить логирование и оповещения, проверять выполнение.

Часто задаваемые вопросы (FAQ)

Q: Где cron хранит свои задания?

A: Пользовательские crontab-файлы находятся в /var/spool/cron/crontabs/, системный — /etc/crontab, а для периодических задач есть каталоги /etc/cron.daily/, /etc/cron.hourly/ и т. д.

Q: Как перенаправить вывод задачи в лог?

A: Добавьте >> /path/to/log 2>&1 в конец строки crontab.

Q: Почему мой скрипт работает при ручном запуске, но не работает в cron?

A: Частые причины — PATH/окружение, отсутствие прав, GUI-зависимость, и отсутствие экранирования %.

Q: Как избежать одновременного запуска нескольких копий задачи?

A: Используйте flock или проверку lock-файла внутри скрипта.

Заключение

Cron — простой, но мощный инструмент для автоматизации задач в Linux. Он остаётся актуальным благодаря своей надёжности и распространённости. Однако важно понимать его ограничения и дополнять его средствами вроде anacron или systemd timers там, где это необходимо. Используйте шаблоны, тестируйте задачи, логируйте результаты и применяйте рекомендации по безопасности, чтобы ваши автоматизированные процессы были устойчивыми и прозрачными.

Image Credit: schedule board by Gonzalo Aragon via Shutterstock