Debian | PHP-FPM не находит директорию сайта и падает в ошибку. Все сайты на PHP, обслуживаемые NGINX, не работают.

Однажды может возникнуть такая ситуация, что PHP-FPM не сможет найти нужную директория сайта на сервере.

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

В чём тут проблема? Как пришли к проблеме?

Предположим у нас был сайт. Он был написан на PHP. Этот сайт успешно работал в связке с NGINX.

И вот пришло время избавиться от домена у регистратора, отлинковать виртуальный хост на веб-сервере и удалить папку с файлами на сервере.

Мы сделали все эти действия. И жили так ещё некоторое время.

И вот однажды перезагрузили сервер (или виртуальную машину) и у нас отвалились все остальные сайты, которые работали тоже на PHP. Как такое могло произойти?

Поиск проблемы

Прежде чем паниковать и хвататься за всё подряд, нужно проанализировать ситуацию по классической цепочке:

Шаг № 1

Сначала проверяем работоспособность (состояние) веб-сервера NGINX. Если он способен отдать статический «***.html» файл, значит он работает и проблема не в веб-сервере.

Шаг № 2

Проверяем существование и работоспособность самого PHP. Если он установлен, то всё ок.

Шаг № 3

Пытаемся обратиться в браузере к НУЖНОМУ домену. Если мы знаем о каком домене идёт речь (о домене какой папки на сервере), то скорее всего браузер тупо не сможет найти никакой записи в DNS и вернёт ошибку в дизайне самого браузера.

Шаг № 4

Пытаемся обратиться в браузере к ДРУГОМУ НЕРАБОТАЮЩЕМУ домену, который хостится на этом сервере, и который тоже работает на PHP.

Если видим ошибку 502, значит это проблема серверной части, которая обрабатывает запрос после веб-сервера. То есть NGINX куда-то передал запрос, а в ответ ничего не получил внятного.

Шаг № 5

Читаем журналы ошибок веб-сервера. Это может быть общий журнал по всем доменам (виртуальным хостам), а может быть и отдельный лог по каждому виртуальному хосту. Вдруг у вас проблема в чём-то ещё. Будет полезно взглянуть.

Очень вероятно, что мы найдём что-то вроде «connect() to unix:/run/php/php7.3-fpm.sock failed (2: No such file or directory) while connecting to upstream»

No such file or directory — Данный файл или каталог отсутствует

Это уже что-то полезное. Но если мы знаем, что у других сайтов не производились изменения в настройках виртуальных хостов NGINX, значит вся проблема в работе самого FPM (FastCGI Process Manager)

Шаг № 6

Анализ состояния самого PHP-FPM. Проверяем командой в Debian (укажите свою версию PHP на какой сокет вы пробрасываете запросы из NGINX):

service php7.3-fpm status

или

service php7.3-fpm status

или

service php-fpm status

В случае с нашей ошибкой мы увидим:

Failed to start The PHP 7.3 FastCGI Process Manager.

Нас будут интересовать сообщения, которые идут справа от «ERROR:».

В нашем случае не будет найден pool (пул) для нужного сайта.

И тут возникает вопрос. Откуда он вообще взялся?

ВАЖНО!!!

В PHP-FPM можно настраивать отдельные конфигурационные файлы для работы с каждым сайтом. И если для какого-нибудь сайта остался конфиг, но данные и директория были удалены, то PHP-FPM упадёт в ошибку т. к. не сможет корректно обработать кофигурационный файл.

Шаг № 7

Где искать «потерянный» конфиг, который портит жизнь всем остальным сайтам, работающим на PHP?

Адреса в Debian:

/etc/php/7.3/fpm/pool.d

или

/etc/php/7.4/fpm/pool.d

В этой папке можно увидеть стандартный файл «www.conf«. В идеально простом мире в этой папке должен лежать только один этот файл и больше ничего. Но если не вы делали настройки сервера, то вам придётся за кем-то «подчищать».