#Симптом и границы применимости
После переноса сайта Nginx обслуживает страницы, но периодическая задача перестала выполняться. Важно не искать расписание в Nginx: cron, systemd timer, очередь CMS или панель хостинга запускают задание отдельно.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Не перенесён планировщикФайлы сайта не переносят записи cron автоматически. | На старом сервере было расписание, на новом нет | Сравнить задания для нужного пользователя |
| Неверный путь или версия PHP CLIВ новом окружении php, каталог и права могут отличаться. | В журнале cron ошибка file not found / missing extension | Проверить команду и окружение |
| Задача запускается, но не завершаетсяНаличие cron не означает успешного завершения программы. | Записи запуска есть, но нет результата | Проверить журнал самого сценария |
#Пошаговая диагностика и исправление
- Выясните, что именно должно происходитьНазовите файл или команду задания, ожидаемый интервал и признак успешной работы: новый отчёт, отправленное письмо или запись в журнале. Проверьте историю последнего выполнения в CMS. Не запускайте вручную задания, которые могут отправить письма или изменить базу, до понимания их последствий.
- Найдите, кто запускает заданиеЧерез SSH проверьте cron для пользователя сайта, затем системные таймеры. Учтите, что в панели может быть отдельная таблица заданий, а systemctl list-timers покажет только таймеры systemd. Не вставляйте незнакомые команды из старого сервера без проверки.
- Вывод crontab -l показывает расписание только текущего пользователяLinux · Терминал (Bash)КомандаВывод crontab -l показывает расписание только текущего пользователя.
crontab -lsystemctl list-timers --all --no-pager
- Сравните путь и окружениеИз расписания выпишите абсолютный путь к интерпретатору, скрипту и рабочему каталогу. Узнайте точный путь к PHP CLI через command -v php и версию через php -v. У PHP-FPM и CLI могут быть разные версии и расширения. Если путь после переноса не существует, исправляйте его в панели расписания либо crontab владельца задачи.Linux · Терминал (Bash)КомандаЗапускать в оболочке того пользователя, который выполняет задачу.
command -v phpphp -v
- Исследуйте причину по журналамНа Debian/Ubuntu ищите запуск CRON в системном журнале или journalctl, на иных системах — в штатном журнале планировщика. Если записей о запуске нет, проверьте службу cron и права. Если запуск есть, смотрите стандартный вывод и stderr самого сценария; лучше выделить отдельный ограниченный журнал.
- Пример для систем с cron и systemd; на других дистрибутивах имя службы отличаетсяLinux · Терминал (Bash)КомандаНужен sudoПример для систем с cron и systemd; на других дистрибутивах имя службы отличается.
sudo systemctl status cron --no-pagersudo journalctl -u cron -n 60 --no-pager
- Проверяйте команду без побочных эффектовДля чтения проверьте существование файла, владельца и права. Не запускайте боевую отправку/оплату/очередь повторно. Если в сценарии предусмотрен режим --dry-run, используйте его согласно документации программы, а не придумывайте несуществующий параметр.
- Восстановите расписание и контроль результатаПосле проверки перенесите нужную запись через панель или crontab -e именно у пользователя задачи; сохраните прежнее расписание в копии. Укажите абсолютные пути и рабочий каталог при необходимости. Затем дождитесь очередного запуска и сравните конкретный результат с ожидаемым. Если работа повторяется дважды, проверьте, не активна ли она на обоих серверах.
#Как проверить результат
Убедитесь по журналу планировщика и журналу приложения, что задача выполнилась один раз в нужное время и привела к ожидаемому результату. Проверьте часовой пояс сервера и приложения.
#Если проблема не устранена
Если cron срабатывает, но результата нет, исследуйте права к файлам, сетевые зависимости и переменные окружения. Не относите проблему к Nginx, если веб-сервер только показывает сайт.