Панели хостинга Linux; Nginx / Apache / PHP-FPM (в зависимости от панели)

Панель управления хостингом: после миграции не выполняется задание по расписанию

  • Обновлено
  • Чтение ≈ 3 минуты

Краткий ответ

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

В этой статье
  1. Симптом и границы применимости
  2. Возможные причины и признаки
  3. Пошаговая диагностика и исправление
  4. Проверка результата
  5. Если проблема осталась
  6. Безопасный откат

#Симптом и границы применимости

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

Эта инструкция относится к конкретному сайту в панели управления хостингом, когда его обслуживают Nginx, Apache, PHP-FPM или их сочетание. Названия разделов и доступность SSH зависят от установленной панели и прав пользователя; шаги, которых нет в вашем интерфейсе, выполняет администратор сервера.

#Возможные причины и признаки

Возможная причинаКак узнатьЧто делать
Не перенесена запись планировщикаНа новом сервере список заданий пустВ панели нет задания; старый сервер выполнял егоСоздать запись по исходному описанию
Неверная среда исполненияУказан старый путь к php, рабочему каталогу или пользователюВ ручном запуске ошибка «файл не найден»/нет модуляУточнить текущую команду и версию PHP
Двойной запускНа старом и новом сервере осталось одинаковое заданиеПовторные письма, дубликаты импортаОстановить лишнюю копию после подтверждения

#Пошаговая диагностика и исправление

  1. Проверьте реальный эффект задачиЗафиксируйте, какой файл, запись или письмо должна создавать задача и во сколько с указанием часового пояса. Не используйте отправку массовых писем как тест. Убедитесь, что функция не выполняется асинхронно самой CMS.
  1. Найдите задания в панели и у пользователяВ панели откройте раздел запланированных заданий для нужного пользователя/сайта. На SSH проверьте пользовательскую таблицу cron. Отсутствие записей здесь не исключает systemd timers, которые нужно искать отдельно.
  2. SSH обычного пользователя; systemctl показывает таймеры системы
    Linux · Терминал (Bash)Команда
    SSH обычного пользователя; systemctl показывает таймеры системы. Для cron другого пользователя нужны соответствующие права.
    crontab -l
    systemctl list-timers --all
  1. Сверьте команду со старой копиейИз резервной копии или настроек прежнего сервера восстановите точную команду, путь скрипта, пользователя, окружение и расписание. На новом сервере проверьте существование файлов и версии PHP; для веб-приложений команда php в SSH может отличаться от версии PHP в панели.
  1. Проверьте рабочий каталог и разрешенияЕсли скрипт использует относительные пути, явно задайте рабочую папку; если читает секреты — подтвердите владельца и права без их раскрытия. Не задавайте cron от root, если задача должна работать как пользователь сайта.
  1. Запустите безопасную проверку вручнуюЕсли программа поддерживает режим тестирования, выполните его от того же пользователя, что указан в расписании. Для задач с платежами, почтой или удалением используйте тестовую среду, а не запуск реального действия. Перенаправьте диагностические сообщения в закрытый журнал.
  1. Восстановите штатное расписаниеВ панели укажите подтверждённую команду и нужный интервал, проверьте часовой пояс. На сервере при необходимости используйте системный журнал cron или журналы конкретного планировщика. Если ранее были одновременно cron CMS и системный cron, оставьте один документированный способ.
  1. Проверьте один период и исключите дублированиеДождитесь ближайшего срабатывания и сравните журнал/результат. Убедитесь, что старый сервер не запускает тот же импорт. Если запуск отсутствует — изучите журнал планировщика, а не меняйте весь серверный стек.

#Проверка результата

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

#Если проблема осталась

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

#Безопасный откат

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

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.