← Все статьи

SiteGuard16 мин чтения

Cron-задачи: как настроить расписание и убедиться, что задания выполняются

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

Разберём расписание crontab, настройку через панель и SSH, журналы, повторы и типичные сбои. Примеры помогут владельцу сайта и администратору проверить начало процесса и полезный результат.

Cron-задачи: что это и зачем они нужны сайту

Cron проверяет расписание и в подходящий момент запускает указанную команду от имени определённого пользователя. Сам планировщик не знает, сколько товаров должно обновиться и дошёл ли отчёт до менеджера.

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

Какие операции подходят для расписания

  • Подготовленный обмен каталогом, ценами и остатками.
  • Формирование отчётов и файлов для внешних систем.
  • Обновление служебных данных и выполнение предусмотренного обслуживания.
  • Запуск проверенной процедуры резервного копирования с отдельным контролем восстановления.
  • Вызов обработчика отложенных событий, если такую модель поддерживает приложение.

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

Чего cron не гарантирует

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

Для бизнеса вопрос звучит конкретно: насколько свежими должны быть остатки, когда ожидается отчёт и кто узнает о задержке? Эти ответы важнее формулировки «cron настроен».

Как устроена строка crontab

В обычной пользовательской таблице crontab сначала идут пять полей времени, затем команда. Базовая запись читается слева направо: минута, час, число месяца, месяц, день недели. Поля разделяются пробелами; вся команда задания находится на одной строке.

ПолеОбычный диапазонЧто выбирает
Минута0–59Минуту внутри часа
Час0–23Час суток
Число месяца1–31Календарное число
Месяц1–12Месяц года
День недели0–6; в Cronie также 7 для воскресеньяДень недели, где 0 — воскресенье, 1 — понедельник

Звёздочка * означает все допустимые значения поля. Запятая задаёт список, дефис — диапазон, а запись вроде */15 — шаг внутри поля. Формат и расширения описаны в руководстве crontab(5) проекта Cronie. Возможности веб-панели или другого планировщика нужно сверять отдельно.

Пользовательская и системная таблицы отличаются

В таблице, открытой через crontab -e, имя пользователя между расписанием и командой не добавляют: владелец уже определяется самой таблицей. Для системных файлов /etc/crontab и /etc/cron.d/ обычно предусмотрено дополнительное поле пользователя. Поэтому перенос строки из одного формата в другой без проверки может сломать запуск.

Ниже все полные строки расписания относятся именно к пользовательскому crontab. В формах хостинга время и команда могут заполняться раздельно. В таком случае пять полей не нужно повторно вставлять в поле команды.

Не путайте классический cron с похожими форматами

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

Примеры cron-расписаний и их точное значение

В таблице указана только временная часть. Команду добавляют справа в пользовательском crontab либо в отдельное поле панели. Все значения относятся к часовому поясу, который применяет конкретный планировщик.

РасписаниеКогда запускаетсяЧто важно учитывать
*/15 * * * *В 00, 15, 30 и 45 минут каждого часаЭто сетка минут, а не пауза после завершения программы
10 * * * *На десятой минуте каждого часаНапример, 09:10, 10:10 и 11:10
30 3 * * *Каждый день в 03:30Проверьте часовой пояс и длительность работы
0 9 * * 1-5С понедельника по пятницу в 09:00Государственные праздники сами по себе не учитываются
0 8,12,16 * * *Ежедневно в 08:00, 12:00 и 16:00Ноль в поле минут ограничивает запуск началом часа
15 2 1 * *Первого числа каждого месяца в 02:15Это календарный запуск, а не интервал в 30 суток
30 4 * * 0По воскресеньям в 04:30Нумерацию дней проверьте в интерфейсе своей системы

Почему шаг не означает отсчёт от предыдущего запуска

Если задача с */15 стартовала в 10:15 и закончилась в 10:22, следующий подходящий момент остаётся 10:30. Если она ещё работает, новое срабатывание расписания само по себе не обязано ждать её окончания.

Шаг применяется внутри диапазона поля. Например, */40 в минутах выбирает 00 и 40: между 10:40 и 11:00 будет 20 минут. Для строгого интервала от завершения работы нужен другой механизм или логика приложения.

Число месяца и день недели: важная ловушка

В распространённой логике Cronie, когда оба поля ограничены, используется условие «или». Запись 0 9 1 * 1 выбирает 09:00 первого числа месяца и понедельников, а не только первое число, выпавшее на понедельник. Для сложного календарного правила обычно проще оставить понятное расписание, а дополнительное условие проверить в программе. Поведение конкретного продукта обязательно сверяют с его документацией.

Проверьте даты, которых не бывает

Запуск на 31-е число не произойдёт в месяце без такого числа. Если нужен последний день месяца, нельзя заменять его постоянным 31. Отдельно проверьте границу года, февраль и бизнес-календарь.

Как учитывать часовой пояс и изменение времени

Прежде чем выбирать 03:30, запишите, чьё это время: сервера, панели, приложения или сотрудников. Сайт может показывать московское время, а сервер использовать UTC. Настройки CMS не обязательно меняют расписание системного cron.

Где задаётся часовой пояс

Панель хостинга может предлагать отдельный выбор зоны. В Cronie есть переменная CRON_TZ для таблицы, но считать её переносимой на любую реализацию нельзя. Переменная окружения TZ внутри запускаемой программы тоже не всегда меняет момент, в который планировщик решает её вызвать.

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

Что происходит при переходе на летнее или зимнее время

Поведение зависит от реализации и типа расписания. Например, документация службы Cronie описывает специальную обработку небольших сдвигов времени для определённых фиксированных заданий. Поэтому общее утверждение «cron всегда пропускает или дважды запускает задачу» некорректно.

Если операция привязана к местному времени региона с сезонным переводом часов, включите эти даты в проверку. Для технической задачи без такой привязки можно согласовать UTC, если платформа это поддерживает. При этом бизнес-правило «начало рабочего дня по местному времени» нужно сохранить осознанно.

Подготовьте команду, которая работает в окружении cron

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

Используйте нужный интерпретатор и явные пути

На хостинге могут быть разные версии PHP для сайта и командной строки. Выберите тот исполняемый файл, который подходит приложению. Аналогично для Python указывают интерпретатор нужного окружения, а не полагаются на случайно найденную системную версию.

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

Не рассчитывайте на настройки интерактивной оболочки

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

Дайте пользователю задания необходимые права на чтение кода и запись результата. Запуск от root не является стандартным исправлением проблемы доступа. Для задачи сайта обычно нужен пользователь проекта; более широкие права должны иметь конкретное обоснование.

Особенность символа процента

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

Секреты и HTTP-вызовы

Не добавляйте пароль базы или постоянный токен в публичный URL задания. Адреса и командные строки могут попадать в журналы. Используйте предусмотренное приложением защищённое хранение конфигурации и ограниченные учётные данные.

Если задача запускается через HTTP, проверьте метод запроса, HTTPS, авторизацию, перенаправления и ограничения времени. Получение страницы входа с кодом 200 не означает выполнение операции. Для локального сценария часто удобнее документированный CLI-режим: он не зависит от браузерной сессии, но тоже требует корректного окружения.

Как настроить cron в панели хостинга или через SSH

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

Настройка через панель

  1. Откройте раздел планировщика и убедитесь, что выбрана нужная услуга.
  2. Назовите задачу по назначению: например, «Формирование отчёта каталога».
  3. Выберите тип запуска и подходящую версию интерпретатора.
  4. Укажите файл или команду в формате, которого требует панель.
  5. Настройте время, часовой пояс и доступный способ получения ошибок.
  6. Сохраните задачу и проверьте ближайшее срабатывание вместе с результатом.

Например, Timeweb описывает управление через раздел «Crontab»: редактирование утилитой на сервере недоступно, а поле пути к файлу заполняется относительно домашней директории. Панель также позволяет выбрать часовой пояс и получать отчёты об ошибках. Эти особенности не следует автоматически переносить на других поставщиков.

Настройка пользовательского crontab

Если услуга разрешает управление по SSH, сначала посмотрите существующую таблицу:

crontab -l

Сохраните её текущий текст в рабочей документации, затем откройте редактирование:

crontab -e

Добавьте нужную строку, сохранив остальные задания. После выхода снова выполните crontab -l и проверьте установленный текст. Назначение ключей описано в руководстве crontab(1). Не подменяйте редактирование загрузкой нового файла поверх всей таблицы, если не намерены заменить её целиком.

Для временной остановки отдельную строку можно закомментировать через редактор; в панели используйте предусмотренный переключатель. Остановка будущих срабатываний не обязательно завершает уже работающий процесс. Сначала выясните его состояние и безопасный порядок остановки приложения.

Первый запуск должен быть проверяемым

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

Как убедиться, что cron-задача действительно выполнилась

Проверка состоит из трёх уровней: планировщик попытался запустить команду, программа завершилась и нужные данные получены. Журнал cron обычно подтверждает первый уровень. Код завершения относится ко второму, а отчёт приложения и проверка данных — к третьему.

Пример задания с журналом

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

*/15 * * * * /bin/sh /home/siteuser/jobs/run-report.sh >> /home/siteuser/logs/report.log 2>&1

>> дописывает стандартный вывод в журнал; 2>&1 направляет туда же стандартный поток ошибок. Порядок важен: он разбирается слева направо, что поясняет руководство GNU Bash о перенаправлениях. Каталог журнала должен существовать, а пользователь — иметь право записи.

Отдельный файл /home/siteuser/jobs/run-report.sh может фиксировать начало, окончание и код процесса:

#!/bin/sh
cd /home/siteuser/project || exit 1
/usr/bin/date -u '+start %Y-%m-%dT%H:%M:%SZ'
/usr/bin/php /home/siteuser/jobs/report.php
job_status=$?
/usr/bin/date -u '+finish %Y-%m-%dT%H:%M:%SZ'
printf 'exit_code=%s\n' "$job_status"
exit "$job_status"

Этот пример показывает обвязку, а не реализует сам отчёт. Пути /usr/bin/php и /usr/bin/date необходимо сверить на своей площадке. Проценты находятся в отдельном файле, поэтому не разбираются как специальные символы строки crontab.

Что подтверждает код выхода

Нулевой код обычно означает успех по правилам программы. Но если она проглотила исключение или считает пустую выгрузку допустимой, результат для бизнеса может оказаться неверным. Код нужно сохранять сразу после проверяемого процесса: последующая успешная команда иначе изменит наблюдаемое значение.

Договоритесь, какой результат приложение считает успешным. Для импорта это может быть завершённая партия с количеством обработанных объектов и контрольным идентификатором. Для отчёта — созданный файл нужного периода. Для резервирования — копия в конечном хранилище, пригодность которой проверяется отдельным восстановлением.

Настройте контроль отсутствующего результата

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

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

Не убирайте весь вывод в /dev/null до налаживания контроля. Журнал храните вне публичной директории, без секретов, с ограничением размера и срока хранения. Удобный отчёт помогает специалисту восстановить ход работы без догадок.

Как избежать пересечений и правильно обрабатывать повторы

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

Блокировка через flock

На Linux при доступной утилите flock можно согласовать одиночный запуск. Пример команды для подготовленной задачи:

/usr/bin/flock -n /home/siteuser/locks/report.lock /bin/sh /home/siteuser/jobs/run-report.sh

По руководству flock из util-linux, ключ -n не ждёт освобождения занятой блокировки и завершает попытку с ошибкой. Это пропуск запуска, который нужно учитывать в журнале или контроле, а не считать выполненной работой. Каталог блокировки должен существовать и быть доступен нужному пользователю.

Все конкурирующие запуски должны использовать совместимую схему блокировки. Один lock-файл на сервере не координирует автоматически работу нескольких независимых серверов. Для распределённого приложения механизм выбирают на уровне его архитектуры; особенности сетевой файловой системы тоже имеют значение.

Повтор не должен создавать повторный результат

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

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

Что делать с зависшими заданиями

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

Чем WP-Cron отличается от системного cron

WP-Cron — механизм планирования событий внутри WordPress. По официальному описанию, в стандартной схеме проверка наступивших событий связана с загрузками страниц. Поэтому малопосещаемый сайт может выполнить запланированную операцию позже ожидаемого времени. Это не отдельная постоянно работающая служба Linux.

Также различается модель расписания: WordPress использует время первого события и интервалы, а пользовательский crontab обычно задаёт календарные совпадения. Одинаковое слово cron в названии не означает одинаковую конфигурацию.

Когда используют внешний планировщик

Для более управляемого запуска можно настроить системный или предоставленный хостером планировщик, который вызывает предусмотренный обработчик WordPress. Официальная инструкция по подключению WP-Cron к системному расписанию рассматривает этот вариант и настройку DISABLE_WP_CRON.

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

Проверяйте события, а не только обращение к файлу

Убедитесь, что запланированная публикация или другое тестовое событие действительно обработано. Посмотрите список и состояние задач подходящим инструментом; варианты приведены в руководстве по проверке WP-Cron. Ошибка плагина может мешать событию даже при исправном внешнем расписании.

Не запускайте все события вручную на рабочем магазине без понимания их назначения. Некоторые из них меняют данные или отправляют уведомления. Для диагностики выберите контролируемый сценарий.

Почему cron-задача не выполняется: порядок диагностики

Идите от расписания к программе и данным. Если команда не работает вручную в нужном окружении, изменение минут в crontab её не исправит. Если вручную всё хорошо, сравните параметры запуска и подтвердите сам вызов.

СимптомВероятное направление проверкиЧто подтвердить
Нет следов запускаЗадача отключена, другое время или пользователь, служба недоступнаАктивное расписание и подходящий момент по нужной зоне
Вручную работает, из cron — нетПути, рабочий каталог, окружение, версия интерпретатораОдинаковые существенные условия запуска
Permission deniedПрава к файлу, каталогу, интерпретатору или результатуДоступ именно пользователя задания
Журнал пустПеренаправление, права записи, отсутствие вывода или самого вызоваСоздание проверочной записи и правильный путь журнала
Процесс начался, но нет завершенияДолгая операция, ожидание сети, блокировка, остановка процессаСостояние процесса, длительность и ошибку приложения
Код 0, а данные старыеНеполная проверка успеха, другое окружение, пустой источникИдентификатор и содержимое фактического результата
Операции дублируютсяНесколько расписаний, пересечение запусков, повтор без защитыЕдиную схему запуска и обработку повторов

Что проверить на своём сервере

Администратор проверяет установленную реализацию, состояние службы и системные журналы. Название службы и расположение записей зависят от дистрибутива: нельзя обещать, что у всех есть один и тот же файл cron.log. Отсутствие отдельного файла ещё не означает отсутствия журнала.

Сопоставьте отметку планировщика с журналом приложения по времени, пользователю и команде. Учтите лимиты памяти, диска и процессов, сетевые ошибки, недоступность базы и изменения учётных данных. Исправляйте подтверждённую причину и повторяйте ограниченный тест.

Что передать поддержке хостинга

Подготовьте идентификатор задачи, время с часовым поясом, команду без секретов, ожидаемый и фактический результат, сообщение ошибки. Укажите, работает ли тот же сценарий вручную и когда он последний раз завершался успешно. Это гораздо полезнее, чем просьба «проверьте cron» без конкретного запуска.

Как посмотреть cron-задачи пользователей и организовать контроль

crontab -l показывает таблицу текущего пользователя, а не все расписания сервера. Если администратор обладает нужными правами, таблицу определённой учётной записи можно запросить явно:

sudo crontab -u siteuser -l

siteuser — учебное имя, которое заменяют нужным пользователем. Помимо пользовательских таблиц, учитывайте системные файлы, задания панели, расписания внутри CMS и другие механизмы. Просмотр одного crontab не является полным аудитом автоматизации. Системные места назначения описаны в руководстве cron(8).

Карточка задания помогает пережить смену специалиста

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

После переноса сайта проверьте, что задача включена на новой площадке и не продолжает независимо изменять данные на старой. При смене паролей, путей или версии PHP обновите связанные задания и повторите приёмку.

Чек-лист готового cron-задания

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

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

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

Как запускать cron каждые пять минут?

В классическом пятичастном расписании используют */5 * * * *. Это минуты 00, 05, 10 и далее по сетке часа. Проверьте длительность программы: интервал не препятствует пересечению экземпляров.

Можно ли задать запуск каждые несколько секунд?

У обычного cron минимальное поле — минута. Если требуется секундная частота, выбирают подходящий планировщик, очередь или постоянно работающий обработчик. Выражение с дополнительным полем секунд из другого продукта нельзя просто вставить в пользовательский crontab.

Что означает звёздочка в расписании?

Все допустимые значения соответствующего поля. Звёздочка в поле месяца снимает ограничение по месяцу, сохраняя остальные условия. Логику сочетания числа месяца и дня недели проверяют отдельно.

Будет ли задача работать, если компьютер владельца выключен?

Да, если она настроена на работающем сервере, а не на локальном компьютере. Доступность сервера, службы и приложения всё равно необходима. Закрытие браузера владельца само по себе не останавливает серверный cron.

Почему нет письма об ошибке?

Возможны отсутствие вывода, перенаправление, неуказанный адрес, проблема доставки или иные правила панели. Проверяйте механизм уведомлений отдельно. Отсутствие письма не заменяет журнал и подтверждение результата.