Cron не запускает задание: пользователь, путь и окружение

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

Выберите один пропущенный запуск

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

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

Проверьте, какой именно cron используется

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

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

Что отличается от ручного запуска

Таблица не утверждает, что каждый cron всегда запускает проект из одной определённой папки или с одинаковым PATH. Она показывает различия, которые нужно измерить в своей системе. Успех команды из другого контекста не является проверкой условий планировщика.

Сделайте пути и зависимости явными

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

В Cronie оболочка по умолчанию — /bin/sh, если настройкой SHELL не задано другое. Поэтому конструкция, успешно проверенная в иной оболочке, требует отдельной сверки. Не запускайте всё от root как способ обойти неизвестную причину: сначала подтвердите конкретный недостаток доступа или различие среды.

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

Расписание и журнал могут говорить о разном времени

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

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

Диагностический проход без повторных действий

1. Найдите ожидаемый момент выполнения и проверьте, установлена ли задача в нужном месте.
2. Получите свидетельство старта команды или подтвердите его отсутствие по доступной диагностике.
3. Для стартовавшей команды сохраните вывод и завершение, сопоставьте контекст с ручной проверкой.
4. Проверьте бизнес-результат: файл, обработанный период, подтверждённое состояние операции.
5. Перед повторным запуском установите, не выполнена ли часть действий уже и безопасно ли повторение.

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

Нулевой код ещё не означает готовый отчёт

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

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

Как заметить следующий пропуск

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