Crontab в Linux: автоматизация задач

Автоматизация задач с crontab в Linux — ноутбук с терминалом и строкой планировщика

Что такое crontab

Crontab — это системный инструмент (демон cron и файлы crontab), который выполняет команды по расписанию. Он подходит для периодических задач: резервных копий, сборов логов, проверок состояния сервисов, рассылок и напоминаний. Простое определение: cron запускает команды по расписанию, а crontab — это файл пользователя с этими заданиями.

Коротко: демон cron — фоновый процесс. Crontab — файл расписания для отдельного пользователя.

TL;DR технически

Cron работает постоянно и читает файлы crontab.
Каждый пользователь имеет отдельный crontab.
Формат записи: 5 полей времени + команда.
Для подавления вывода добавьте перенаправление в /dev/null.

Основные команды crontab

crontab -l — показать все задания текущего пользователя.
crontab -e — отредактировать crontab текущего пользователя.
crontab -r — удалить все задания текущего пользователя.

Если нужно управлять crontab другого пользователя, добавьте опцию -u при запуске от root: sudo crontab -u jdoe -e

Важно: под root используется отдельный crontab; будьте осторожны и используйте -u явно.

Формат задания crontab

Каждое задание занимает одну строку и имеет формат:

MINUTE HOUR DAY MONTH WEEKDAY COMMAND

Поле — значение — диапазон — что означает:

Minute — 0–59 — минута запуска.
Hour — 0–23 — час запуска.
Day — 1–31 — день месяца.
Month — 1–12 — месяц.
Weekday — 0–6 (воскресенье = 0 или 7) — день недели.
Command — любая команда или путь к исполняемому скрипту.

Используемые шаблоны:

- — любой допустимый вариант для поля.
a,b — перечисление значений (через запятую).
a-b — диапазон.
*/n — шаг (каждые n единиц).

Примеры:

Запуск каждый день в 03:20:

20 3 * * * /root/backup.sh

Запуск каждый час в 20 и 50 минут:

20,50 * * * * /path/to/command.sh

Запуск каждые 3 часа в 15 минут:

15 */3 * * * /path/to/command.sh

Подавление вывода и логирование

По умолчанию вывод задания (stdout/stderr) может попадать в локальную почту пользователя. Чтобы заглушить вывод, добавьте:

> /dev/null 2>&1

Пример полного задания, без вывода и с запуском резервного копирования:

0 6 15 * * /path/to/backup.sh > /dev/null 2>&1

Если нужно логировать, перенаправьте вывод в файл с ротацией через logrotate или используйте системные логи:

*/30 * * * * /usr/local/bin/job.sh >> /var/log/myjob.log 2>&1

Как добавить задание

Стандартный способ — отредактировать crontab через crontab -e:

crontab -e

Редактор (обычно nano или vim) откроет файл. Каждая строка — одно задание. Комментарии начинаются с #.

Быстрый способ добавить строку из командной строки (уже существующие задания сохранятся):

(crontab -l; echo "0 14 * * 0 /path/to/command.sh") | crontab -

Этот приём выводит текущий crontab, добавляет строку и устанавливает новый crontab.

Просмотр и удаление заданий

Показать задания: crontab -l
Удалить все задания: crontab -r

Чтобы удалить только одно задание, откройте crontab -e и удалите строку, затем сохраните.

Практические примеры

1) Звуковые напоминания каждый два часа

Если у вас есть аудиофайл /home/myuser/myalert.wav и у вас настроено воспроизведение в сессии, можно запустить:

0 */2 * * * aplay /home/myuser/myalert.wav

Замечание: aplay работает в консоли. Для графической сессии может потребоваться вызов через dbus или использовать системный медиа-проигрыватель с указанием DISPLAY и XAUTHORITY.

Пример для воспроизведения в пользовательской сессии (вариант):

0 17 * * 5 DISPLAY=:0 XAUTHORITY=/home/myuser/.Xauthority /usr/bin/xdg-open /home/myuser/friday_song.mp4

2) Резервное копирование с помощью rsync

Автоматическое копирование каталога на удалённый сервер:

0 2 * * * /usr/bin/rsync -a --delete /home/myuser/data/ backup@example.com:/backups/myuser/ >> /var/log/rsync-backup.log 2>&1

Советы: используйте SSH-ключи без пароля (или ssh-agent), ограничьте права на ключи и храните логи.

3) Проверка доступности сайтов и уведомление по e-mail

Пример PHP-скрипта для проверки сайтов и отправки письма при падении. Сохраните файл как /home/myuser/check_sites.php и выполните через PHP CLI.

 0) {
    mail($email, "Urgent - Sites Down!", "Your bot has detected the following sites are currently down:\n" . implode("\n", $down));
}

exit(0);

function check_url(string $url): int
{
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_FRESH_CONNECT, true);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
    curl_exec($ch);
    $status = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    return $status;
}

Добавьте в crontab запуск каждые 5 минут и заглушите вывод:

*/5 * * * * /usr/bin/php /home/myuser/check_sites.php > /dev/null 2>&1

Замечание: убедитесь, что команда mail или альтернативный MTA настроены на сервере.

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

Cron подходит для простых периодических задач. systemd timers дают более гибкие возможности (отложенный запуск, зависимость от юнитов, лучшая интеграция с журналом systemd). Если ваша система использует systemd (современные дистрибутивы), рассмотрите systemd timers для сложных сценариев.

Мини-сравнение:

Простота: cron — проще.
Интеграция с systemd: systemd timers — лучше.
Отслеживание: systemd логирует в journal.
Портативность: cron — везде, где есть cron.

Лучшие практики и безопасность

Не запускать необдуманно как root: ограничьте привилегии.
Храните скрипты в контролируемых директориях (/usr/local/bin или /home/имя/scripts).
Давайте скриптам понятные имена и журналируйте результаты.
Проверяйте окружение: crontab использует минимальные переменные окружения. Явно указывайте PATH внутри скрипта или в верхней части crontab:

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

Защищайте SSH-ключи и не держите пароли в скриптах.
Проводите ротацию логов (logrotate) для файлов логов заданий.

Отладка и частые ошибки

Задание не выполняется: проверьте формат, PATH, права и SHELL.
Скрипт работает вручную, но не по cron: проверьте переменные окружения, абсолютные пути и права на исполнение.
Письма от cron приходят, но нет вывода: проверьте stderr и stdout — возможно, всё идёт в /var/mail/youruser.

Совет: в скриптах добавьте явное логирование в файл и проверку ошибок, чтобы легче было отлаживать.

Примеры полезных шаблонов и сниппеты

Cheat sheet — часто используемые шаблоны:

Каждая минута:

* * * * * /path/to/script.sh

Каждые 15 минут:

*/15 * * * * /path/to/script.sh

В 2:30 ночи каждое воскресенье:

30 2 * * 0 /path/to/weekly-job.sh

В первый день месяца в 03:00:

0 3 1 * * /path/to/monthly-job.sh

Методология добавления критического задания (мини-SOP)

Написать и протестировать скрипт вручную.
Добавить журналирование и обработку ошибок.
Проверить права доступа и зависимости.
Добавить в crontab в тестовом окружении.
Наблюдать 24–72 часа, проверить логи.
Перенести в production при успехе.

Критерии приёмки

Задание запускается в ожидаемое время.
Скрипт завершился с кодом 0 при нормальной работе.
Ожидаемый лог-файл был обновлён.
В случае ошибки отправилось уведомление или запись об ошибке.

Роль‑ориентированные чеклисты

Администратор:

Проверить crontab пользователя и системный cron.
Убедиться в ротации логов и правах.
Настроить мониторинг выполнения.

Разработчик:

Использовать абсолютные пути и проверять окружение.
Добавить unit-тесты для скрипта.
Локально протестировать запуск cron-имитатора.

Пользователь:

Понимать, что запускаете и с какими правами.
Не хранить секреты в простом виде в скриптах.
Тестировать расписание до его постоянного использования.

Модель мышления и когда NOT использовать cron

Ментальная модель: cron — таймер, который «тикает» по расписанию. Если задача зависит от событий, состояния других сервисов или требует сложных зависимостей, лучше использовать системный менеджер (systemd), очередь задач (RabbitMQ/Redis) или специализированный orchestrator.

Когда cron не подходит:

Требуется точная координация между задачами.
Нужно повторно запускать задачу при сбое с экспоненциальной задержкой.
Задача должна срабатывать на события в реальном времени.

Проверочные тесты и приёмка

Создать простую задачу, которая пишет timestamp в файл и проверить, что файл обновился.
Проверить поведение при перезапуске службы cron.
Проверить уведомления об ошибках (если предусмотрены).

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

Cron присутствует в большинстве дистрибутивов.
Если вы переходите на systemd, спланируйте миграцию: создайте .service и .timer файлы, перенесите логику и переменные окружения.

Примеры ошибок и обходные решения

Проблема: команда доступна в интерактивной сессии, но не из cron.
Решение: укажите абсолютный путь или задайте PATH в crontab.
Проблема: cron отправляет e‑mail с выводом, много писем.
Решение: перенаправить вывод в лог и включить фильтры уведомлений.

Примечания по конфиденциальности и безопасности

Не храните пароли в скриптах. Используйте менеджеры секретов или ключи с ограниченными разрешениями.
Ограничьте доступ к файлам crontab и самим скриптам.
Регулярно проверяйте, кто и какие задания добавляет.

Решение: использовать cron или systemd — простая логика (Mermaid)

flowchart TD
  A{Требуется периодический запуск?} -->|Да| B{Зависимости от systemd или логирование важны?}
  A -->|Нет| Z[Использовать события/очередь]
  B -->|Да| C[Использовать systemd timers]
  B -->|Нет| D[Использовать cron]
  C --> E[Написать .service и .timer]
  D --> F[Добавить crontab и логирование]

Короткая проверка перед деплоем

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

Итоги

Crontab остаётся простым и мощным инструментом для автоматизации рутинных задач в Linux. Он идеален для запуска периодических скриптов и простых задач, но для более сложных сценариев стоит рассмотреть systemd timers. Соблюдайте базовые правила безопасности, логируйте выполнение и тестируйте скрипты перед добавлением в crontab.

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