Настройка крона в Linux

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

Cron — это стандартный планировщик задач в Linux. Он работает как системная служба и по расписанию запускает команду, скрипт или программу без участия пользователя. Через crontab задают время, период и правило, по которому должно начинаться выполнение. Поэтому настройка cron особенно полезна, когда нужно автоматически делать резервное копирование, очищать log, запускать php-обработчики, обновлять данные сайта или выполнять сервисные проверки. В последнее время cron часто используют и на обычных VPS, и на виртуальный машине у разных провайдеров, где через него удобно запускать служебные операции без ручного участия администратора.

Логика работы простая. Демон cron раз в минуту читает записи crontab, сверяет текущее время с указанными параметрами и запускает нужные процессы от имени пользователя или системной учетной записи. Именно поэтому этот инструмент стал базой для регулярной работы сервера: он помогает держать расписание под контролем, экономить ресурсы и не запускать важные действия вручную.

Где хранятся файлы crontab и как они обрабатываются

В Linux системный cron файл обычно расположен в /etc/crontab, а дополнительные задания часто лежат в /etc/cron.d/. Пользовательские записи система хранит в каталоге /var/spool/cron/ или рядом с ним, в зависимости от сборки. Каталоги /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly и /etc/cron.monthly обрабатывает run-parts, который по очереди запускает содержимое папок. Для ноутбуков и машин с непостоянной активностью этот механизм нередко дополняет anacron, чтобы нужные действия не пропускались после паузы в работе. Эти каталоги содержат системные и пользовательские записи, разделенных по назначению и интервалу запуска. Если открыть сервер через ssh, можно быстро проверить, как устроена файловой структура, какие пути уже доступны, где лежит нужный file, и как run-parts обходит каталоги без лишнего вмешательства через панель, интерфейс или меню хостинга.

Структура каталогов и файлов, связанных с cron

• /etc/crontab — основной системный файл cron.
• /etc/cron.d/ — отдельные системные задания cron.
• /var/spool/cron/ — пользовательские crontab-файлы.
• /var/spool/cron/crontabs/ — пользовательские crontab в Debian и Ubuntu.
• crontab пользователя — личные задания, которые редактируют через crontab -e.
• run-parts — запускает скрипты из стандартных cron-каталогов.
• anacron — выполняет пропущенные задания после включения системы.

Стандартные директории cron

• /etc/cron.hourly/ — каждый час
• /etc/cron.daily/ — каждый день
• /etc/cron.weekly/ — каждую неделю
• /etc/cron.monthly/ — каждый месяц

Синтаксис crontab

Запись в crontab состоит из шести частей: сначала идут пять полей расписания, затем — строка с действием. Все элементы разделяются пробелами. Такой синтаксис нужен, чтобы система точно понимала, когда именно должна выполнять нужные задания.

Стандартная схема выглядит так:

минута час день_месяца месяц день_недели команда

Все поля идут в одной строке без лишнего пространства и читаются слева направо. В англоязычной документации первое поле нередко называют minute, а команда в конце может указывать как на локальный скрипт, так и на внешний путь вида /path/to/script.sh. Чтобы запись читалась без путаницы, удобно смотреть на нее слева направо. Сначала задают, в какую минуту и в какой час должно начаться действие. Затем указывают календарные условия. После этого добавляют то, что требуется выполнить.

• 0 2 * * * /usr/bin/php /home/user/scripts/task.php — запуск в 02:00 ежедневно
• 30 6 * * 1 /usr/local/bin/report.sh — старт по понедельникам в 06:30
• 15 14 1 * * /usr/bin/backup-command — выполнение первого числа в 14:15

Например, можно создать отдельные записи на пятницу, на первое число января или на любые другие фиксированные даты, если это нужно для отчетов, очистки или архивации. У новичков чаще всего встречаются три промаха. Первый — перепутаны позиции полей. Второй — указаны неверные значения, например 60 вместо допустимой минуты. Третий — не задан полный путь к команде или файлу в bin, usr или home. Поэтому при редактировании полезно сначала проверить логику записи, а уже после сохранять изменения.

Специальные символы и их применение

В расписании есть несколько знаков, которые делают запись гибкой. Символ * означает любое допустимое значение. Дефис - задает диапазон: 1-5. Запятую применяют для нескольких отдельных вариантов: 0,12. Косая черта / задает интервал: */5 означает запуск через каждые пять единиц выбранного поля.

Эти правила можно комбинировать. Запись */10 9-17 * * 1-5 подходит для сценария, когда действие должно срабатывать через каждые десять единиц в рабочий промежуток по будням. Такой формат удобен, если нужны точные и повторяемые правила без длинной ручной разбивки. Главное ограничение здесь простое: символы помогают описать диапазоны и интервалы, но не заменяют проверку логики. Перед сохранением полезно еще раз убедиться, что значения полей не выходят за допустимые рамки и не конфликтуют между собой.

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

Для стандартных сценариев удобно брать готовые макросы. Команды cron можно запускать через @reboot после загрузки, @hourly каждый час, @daily или @midnight раз в сутки, @weekly раз в неделю, @monthly раз в месяц, @yearly или @annually раз в год. Такой формат короче обычной записи и быстрее читается при редактировании. Макрос @reboot особенно удобен в сценариях, где нужна перезагрузка фонового процесса сразу после старта системы. Это может быть инициализация мониторинга, запуск очереди задач или восстановление сервисной логики после рестарта.

Например, @daily /usr/local/bin/cleanup.sh равен записи 0 0 * * * /usr/local/bin/cleanup.sh. В свою очередь, @reboot /usr/bin/php /home/user/app/init.php подходит для инициализации сервиса сразу после старта системы.

Создание и редактирование crontab файлов

Редактирование заданий cron удобнее всего начинать через crontab -e. Эта утилита открывает файл текущего профиля в том редакторе, который определены в EDITOR или VISUAL. Если переменные не задать заранее, откроется редактор по умолчанию. Поэтому перед началом полезно выбрать удобный вариант и только потом добавить новые записи. Чаще всего редактирование идет через ssh: администратор вводит логин, попадает в нужный аккаунт и уже там открывает crontab -e. Если cron еще не активен, его можно установить через пакетный менеджер, например командой с install, а затем проверить, что редактор и базовая опция запуска настроены корректно.

• Выполнить crontab -e.
• Вставить новую строку с расписанием и действием.
• При необходимости оставить комментарий над записью.
• Сохранить содержимое и закрыть окно.

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

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

Для просмотра текущих записей используйте crontab -l. Эта команда выводит весь список в терминал, поэтому перед любым изменением удобно сделать резервную копию: crontab -l > backup.cron. Полное удаление выполняет crontab -r, и здесь нужна аккуратность: исчезают все записи сразу. Если нужно убрать только один пункт, безопаснее открыть таблицу через crontab -e и удалить нужную строку вручную.

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

• crontab -l — показывает все задания текущего пользователя.
• sudo crontab -l — показывает задания пользователя root.
• crontab -l > backup.cron — сохраняет текущие задания в файл.
• crontab -e — открывает crontab для редактирования.
• crontab -r — удаляет все задания текущего пользователя.
• sudo crontab -r — удаляет все задания пользователя root.
• crontab -l | grep backup — показывает только строки со словом backup.

Права доступа и безопасность

Доступ к планировщику регулируют /etc/cron.allow и /etc/cron.deny. Если есть cron.allow, запуск разрешен только тем, чьи имена указаны в этом списке. Если используется только cron.deny, блокируются перечисленные account. Для безопасности лучше выполнять сценарии без лишних привилегий, а sudo давать только там, где он действительно нужен. Кроме того, стоит заранее проверить права на исполняемый скрипт, указать абсолютный путь, не хранить секреты внутри задания и включить журналирование. Такой подход снижает риск случайного доступа, упрощает защиту сервера и делает обработку сбоев заметно понятнее.

Рекомендации по безопасности

• запускайте задания от пользователя с минимально нужными правами
• не храните пароли и ключи прямо в crontab
• всегда указывайте абсолютные пути к командам и скриптам
• проверяйте права доступа к исполняемым файлам
• не давайте право записи посторонним пользователям на скрипты cron
• перенаправляйте вывод в лог и регулярно его просматривайте
• ограничивайте доступ к cron через /etc/cron.allow и /etc/cron.deny
• проверяйте скрипты перед добавлением в расписание
• не запускайте sudo без реальной необходимости
• для критичных задач настраивайте уведомления об итогах выполнения

Практические примеры настройки cron

Ниже — готовые варианты для частых сценариев. Они помогают быстро собрать рабочее расписание и понять логику записи без долгой теории. Такой cron запуск удобно проверять вручную на тестовом VPS, а уже потом переносить на production.

• * * * * * /usr/local/bin/ping-check.sh — срабатывает каждую единицу первого поля. Подходит для короткого мониторинга.
• 0 * * * * /opt/tools/cache-refresh.sh — стартует в ноль минут каждого часа. Частый вариант для обновления кэша.
• 0 0 * * * /opt/maintenance/cleanup-temp.sh — выполняется в полночь. Удобно для очистки временных каталогов.
• 0 0 * * 0 /opt/backup/weekly-backup.sh — работает по воскресеньям ночью. Подходит для недельного бэкапа.
• 0 0 1 * * /opt/reports/month-open.sh — идет в первый календарный день. Хороший вариант для ежемесячного отчета.
• 0 0 15 * * /opt/billing/check-cycle.sh — стартует 15 числа и подходит для периодических расчетов.
• */10 9-18 * * 1-5 /opt/watch/service-check.sh — запуск по будням в рабочий диапазон. Так часто строят задач cron для контроля приложений, веб-узла или панели управления.

Если нужен запуск с PHP, запись может выглядеть так:

15 3 * * * /usr/bin/php /opt/project/bin/job.php >/dev/null 2>&1

Такой формат сразу задает интервал, путь и перенаправление вывода.

Настройка резервного копирования

Один из самых полезных сценариев с помощью cron — регулярное резервное копирование данных. Для этого обычно создают отдельный sh-файл, который архивирует проект, сохраняет базу, удаляет старые копии и пишет результаты в отдельный журнал. Затем этот сценарий ставят в расписание, чтобы он шел еженедельно в ночной период, когда нагрузка ниже.

Простой пример:

#!/bin/sh
tar -czf /backup/site-$(date +\%F).tar.gz /var/www/project
find /backup -type f -mtime +14 -delete

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

Настройка переменных окружения в cron

У планировщика cron окружение заметно проще, чем в обычной консоли. Он не читает ~/.bashrc и ~/.bash_profile, поэтому многие привычные параметры там недоступны. Именно из-за этого одна и та же строка в терминале может идти нормально, а по расписанию — нет.

Чтобы убрать такие сбои, в начале таблицы явно задают нужные переменные:

SHELL=/bin/sh
PATH=/usr/local/bin:/usr/bin:/bin
HOME=/home/user
MAILTO=admin@example.com

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

Список типичных ошибок при работе с переменными в cron

• рассчитывать, что cron загрузит ~/.bashrc или ~/.bash_profile
• не указывать PATH явно в начале crontab
• использовать короткие команды без полного пути, например php вместо /usr/bin/php
• забывать задать SHELL, если скрипт зависит от конкретной оболочки
• указывать неверный HOME
• не настраивать MAILTO, когда нужен почтовый вывод
• передавать переменные окружения только в терминале, но не в crontab
• использовать переменные, которые существуют в интерактивной сессии, но недоступны cron
• не экранировать специальные символы в значениях переменных
• не проверять окружение вручную перед запуском задачи по расписанию

Отладка и устранение ошибок

Если задача не срабатывает, диагностику лучше идти по шагам. Сначала стоит проверить, активна ли служба: systemctl status cron или systemctl status crond на другой сборке. Затем нужно еще раз посмотреть саму запись: один лишний символ, пустую позицию или неверный диапазон легко пропустить при редактировании.

Следующий шаг — ручной тест. Возьмите ту же строку и запустите ее в консоли от того же имени. Так быстрее понять, связана ли причина с доступом, окружением или самим сценарием. После этого полезно добавить перенаправление в отдельный log-файл:

/opt/job/run.sh >> /tmp/cron-debug.log 2>&1

• неверный формат расписания
• отсутствие права на execute
• не указан полный путь
• команда зависит от shell-переменных
• внутри script есть сбой, который не видно без журнала

Если проверять по этой схеме, источник сбоя обычно находится быстро.

Проверка работы cron через логи

Понять, идут ли задания, проще всего через системные журналы. На RHEL и CentOS часто смотрят /var/log/cron, а на Debian и Ubuntu — /var/log/syslog. Для фильтрации удобно использовать grep CRON /var/log/syslog | tail -20. На системах с systemd полезна и другая команда: journalctl -u cron. В записях обычно видны дата, имя хоста, PID процесса и строка запуска. Если задача завершается с кодом 0, это нормальный результат. Любое другое значение уже повод проверить вывод, адрес почты для уведомления и параметры запуска.

Альтернативы и современные подходы

Сегодня вместо классического механизма часто рассматривают systemd timers. Такой вариант удобен там, где важны зависимости между юнитами, централизованный контроль через journalctl и более тесная связка с инфраструктурой дистрибутива. Для ноутбуков и рабочих станций уместен anacron: он догоняет пропущенные срабатывания после долгого простоя. Для одноразового действия подходит at, когда повторяемый цикл не нужен.

Выбор зависит от сценария. Для небольшой регулярной автоматизации cron по-прежнему хорош своей предсказуемостью. Для новых проектов на современном Linux таймеры systemd нередко оказываются удобнее в сопровождении и наблюдении.

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

Что такое Cron и зачем он нужен?

Cron — это системный механизм автоматического старта команд по заранее заданному графику.

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

Какая правильная настройка Cron?

Самый частый путь — открыть личную таблицу через crontab -e, затем вписать строку с расписанием и действием, сохранить изменения и проверить результат.

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

Какой синтаксис используется в настройке crontab?

Базовый формат состоит из пяти временных колонок и одной части с действием: минута час день_месяца месяц день_недели команда.

Например, запись 0 3 * * * /opt/scripts/job.sh означает ежедневный старт в 03:00. Для гибкости применяют *, диапазоны, списки и шаг.

Как посмотреть список текущих крон-задач?

Для просмотра используют crontab -l.

Команда показывает все активные строки текущего профиля. Перед крупными правками удобно сразу сохранить копию: crontab -l > ~/backup.cron. Так проще вернуть прежнее состояние, если после редактуры что-то пошло не так.

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

Начните с четырех проверок: активна ли служба, корректна ли запись, есть ли права на запуск и указан ли полный путь.

Затем протестируйте ту же команду вручную и добавьте журналирование: /opt/job/run.sh >> /tmp/debug.log 2>&1. После этого источник сбоя обычно становится очевиднее.

Как запустить скрипт по расписанию с помощью крон?

Нужно указать полный путь к сценарию и время старта.

Пример: 30 2 * * 1 /opt/backup/weekly.sh. Такой вариант запустит файл по понедельникам в 02:30. Если внутри используется интерпретатор, его тоже лучше задавать явно, без сокращений и догадок системы.

Какие специальные переменные можно использовать в настройке cron?

Для типовых случаев подходят макросы @reboot, @hourly, @daily, @weekly, @monthly, @yearly.

Кроме них, в верхней части таблицы часто задают SHELL, PATH, HOME и MAILTO. Они влияют на среду выполнения, доставку вывода и предсказуемость запуска.

Где хранятся логи крон?

Расположение зависит от дистрибутива.

На Debian и Ubuntu часто смотрят /var/log/syslog, а на CentOS и RHEL — /var/log/cron. Для быстрого просмотра удобно использовать фильтр grep CRON /var/log/syslog | tail -20. На системах с systemd дополнительно помогает journalctl -u cron.

Как передать вывод cron задачи на email?

Проще всего задать в таблице строку MAILTO=admin@example.com.

Тогда стандартный вывод и сообщения об ошибках будут отправляться на указанный ящик. Если письма не нужны, их можно отключить перенаправлением в /dev/null или сохранить результат в отдельный журнал для последующей проверки.

Чем отличается cron от systemd timers?

Cron проще и привычнее: он хорош для регулярных действий без сложных зависимостей.

Таймеры systemd лучше интегрированы в современную инфраструктуру, удобнее связаны с юнитами и журналами, а также лучше подходят для управляемых сервисных сценариев. Для базовой автоматизации cron обычно хватает с запасом.