#Симптом и границы применимости
После восстановления сайта Apache из резервной копии могут остановиться очереди, отправка писем и задания cron. Apache 2.4 обслуживает HTTP, но не запускает расписание автоматически; восстановление файлов веб-сервера не гарантирует восстановление планировщика и его учётных записей.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Расписание не восстановленоРезервная копия сайта обычно не содержит системный crontab. | В cron/таймерах нет записи запуска | Восстановить расписание под правильным пользователем |
| Путь или версия PHP изменилисьCLI PHP и PHP-FPM могут использовать разные версии. | Планировщик запускает устаревший путь к php/скрипту | Исправить абсолютные пути по фактической системе |
| Две машины выполняют одну задачуРасписание могло остаться активным на прежнем хосте. | После восстановления задача запускается дважды | Проверить старый и новый серверы |
#Пошаговая диагностика и исправление
- Определите безопасный признак работыВ панели CMS уточните, какая фоновая задача остановилась, в какое время она должна срабатывать и какой файл либо запись в БД должен появиться. Не запускайте вручную массовую рассылку, оплату или повторное списание — это может удвоить действие. Отметьте часовой пояс веб-приложения и сервера.
- Найдите реальный планировщикПодключитесь к SSH под пользователем, который ранее исполнял задачу. Выполните crontab -l; команда показывает только задачи этого пользователя. Посмотрите systemd-таймеры и расписание панели хостинга; при отсутствии строки проверьте резервные копии системных настроек.Linux · Терминал (Bash)КомандаНе изменяет расписание; systemctl отображает только systemd-таймеры.
crontab -l; systemctl list-timers --all --no-pager
- Проверьте точность команд и окружениеВ строке расписания найдите абсолютные пути к PHP, скрипту и журналу, а также нужный рабочий каталог. Через SSH запустите command -v php и php -v как тот же пользователь. Если PHP CLI не совпадает с PHP сайта, сравните его расширения и версию; не делайте ссылку php наугад.Linux · Терминал (Bash)Команда
command -v php; php -v; pwd
- Ищите фактический запуск в журналахВ Debian/Ubuntu проверьте состояние cron и его журнал. Если запуск зарегистрирован, а приложение не выполнилось, причина может быть в правах, переменных окружения или БД; снимите код завершения из журнала самого скрипта.
- Для систем с cron и systemd; в других ОС имя службы отличаетсяLinux · Терминал (Bash)КомандаНужен sudoДля систем с cron и systemd; в других ОС имя службы отличается.
sudo systemctl status cron --no-pager; sudo journalctl -u cron -n 80 --no-pager
- Безопасно верните одно расписаниеСкопируйте прежний crontab в файл с ограниченным доступом, затем используйте crontab -e либо панель хостинга владельца задания. Укажите правильные абсолютные пути. Если задача активна на исходном сервере, согласуйте отключение там, чтобы избежать двойного выполнения. Не запускайте боевой сценарий для проверки без поддержки сухого режима.
- Дождитесь очередного запуска и сравните результатПосле исправления убедитесь в единственном срабатывании по журналу планировщика и в ожидаемом результате приложения. Если восстановление затронуло базу, проверьте наличие таблиц и прав без массовой перезаписи. Если остались ошибки, откатите изменение расписания и передайте журнал разработчику.
#Как проверить результат
В штатное время задача сработала ровно один раз и создала конкретный ожидаемый результат; веб-сайт продолжает отвечать без новых ошибок Apache.
#Если проблема не устранена
Если планировщик запускает команду, но она завершается с ошибкой, проверьте права, CLI PHP, зависимости и базу. Перенастройка Apache здесь обычно не помогает.