Работает вручную, но не в cron: проверяем окружение
Почему скрипт работает из терминала, но не из cron: пути, пользователь, рабочий каталог и вывод ошибок.
- Пользователь и путиЯвно задаём команду и рабочий каталог
- Запуск cronУчитываем ограниченное окружение
- Вывод и ошибкиСохраняем журнал и проверяем результат
В терминале отчёт создаётся за секунду, а ночью cron будто ничего не делает. Обычно у фонового запуска другое окружение: короче PATH, другой текущий каталог, нет привычных переменных. Сделаем эти зависимости явными и сохраним вывод задачи, чтобы следующий сбой не пришлось расследовать вслепую.
Делаем зависимости явными
SHELL=/bin/sh
PATH=/usr/bin:/bin
15 3 * * * /usr/local/bin/build-report >> /home/report/logs/report.log 2>&1Учётная запись report и каталог журналов должны существовать заранее. Пользователь задачи должен иметь доступ к входным данным, выходному каталогу и самому скрипту. В пользовательской таблице после пяти полей времени сразу идёт команда. В системном crontab присутствует поле пользователя, поэтому перенос строки между форматами без проверки может привести к неправильному запуску.
Скрипт отвечает за свой каталог
#!/bin/sh
set -eu
cd /srv/reporting
/usr/bin/python3 /srv/reporting/report.pyАбсолютные пути убирают зависимость от поиска команд, а явный cd задаёт основу для относительных путей внутри программы. Если приложение требует виртуальное окружение, укажите его интерпретатор непосредственно. Загрузка всего пользовательского профиля ради одного значения усложняет диагностику. Лучше перечислить нужные настройки и определить отдельный защищённый способ передачи секретов.
Начните с запуска того же скрипта от имени владельца задачи, затем с ограниченным окружением и из другого каталога. Сравните код завершения и журнал. Запишите начало и конец выполнения так, чтобы отличить отсутствие запуска от ошибки внутри отчёта. Стандартный вывод и поток ошибок полезно сохранять вместе, если программе не требуется другой порядок обработки.
Учитываем синтаксис и пересечения
Процент в поле команды cron имеет специальное значение, поэтому сложное форматирование даты удобнее перенести в скрипт. Убедитесь, что расписание соответствует часовому поясу сервера. Пример предполагает обычное ежедневное выполнение и не обещает одинакового поведения при переводе часов. Также проверьте, успевает ли предыдущая задача завершиться до следующего запуска.
Пустой журнал может означать и отсутствие вывода, и ошибку открытия файла. Посмотрите сам отчёт: появился ли он, свежая ли дата, верны ли данные. После исправления дождитесь запуска по расписанию. Успешная команда из терминала ещё не проверяет работу cron.
