Как перезапустить php-fpm: команды и безопасный reload
Перезапустить php-fpm можно командой sudo systemctl restart php8.2-fpm, а на нагруженном сайте безопаснее reload. Разбираем команды и проверку.
Как перезапустить php-fpm без простоя и ошибок
Чтобы перезапустить php-fpm, выполните `sudo systemctl restart php8.2-fpm`, подставив версию PHP, установленную на сервере. Если сайт работает под нагрузкой, используйте `sudo systemctl reload php8.2-fpm`: он применит настройки и не оборвёт текущие запросы.
Перезапуск php-fpm нужен после правок php.ini, изменения пулов, установки расширений и в случаях, когда процессы зависли и сайт отвечает ошибкой 502 или 504. В статье разобраны команды для разных систем и Docker, разница между restart и reload, безопасный порядок действий и проверка результата.
Что такое php-fpm и зачем его перезапускать
PHP-FPM (FastCGI Process Manager) — это менеджер процессов, который выполняет PHP-код для веб-сервера. Nginx или Apache принимает запрос браузера и передаёт его php-fpm через unix-сокет или TCP-порт. Там запрос обрабатывает один из рабочих процессов (воркеров), а готовый ответ возвращается обратно. Все WordPress, Laravel, Bitrix и другие PHP-сайты работают именно по такой схеме.
Воркеры живут долго и держат в памяти настройки, прочитанные при старте. Поэтому изменённый файл `php.ini` или конфигурация пула не вступают в силу сами. Службу нужно перезапустить или мягко перезагрузить, чтобы она перечитала конфигурацию.
Есть и вторая причина. Воркер, который завис на долгом запросе или вышел за лимит памяти, не освобождается сам. Если все слоты `pm.max_children` заняты, новые запросы встают в очередь, и посетители, а вместе с ними поисковые роботы Яндекса и Google получают 502 или 504.
Когда перезапуск php-fpm действительно нужен
- 01
Вы изменили php.ini: memory_limit, upload_max_filesize, max_execution_time или часовой пояс.
- 02
Вы поправили конфигурацию пула: pm.max_children, pm.start_servers, user, group или адрес listen.
- 03
Установили или отключили расширение PHP: redis, imagick, intl, pdo_pgsql.
- 04
Обновили PHP или пакеты и хотите убедиться, что работает новая версия.
- 05
Сайт отдаёт 502 или 504, а в логах видно, что воркеры исчерпаны или зависли.
- 06
Выложили новую версию кода при отключённой проверке времени изменения файлов в OPcache.
- 07
Заметили рост потребления памяти: часть воркеров накопила утечки.
Как узнать точное имя службы php-fpm
Самая частая причина ошибки `Unit php-fpm.service not found` — неверное имя службы. В Debian и Ubuntu версия PHP входит в название: `php7.4-fpm`, `php8.1-fpm`, `php8.3-fpm`. В семействе CentOS, AlmaLinux и Rocky Linux служба чаще называется `php-fpm`, а при установке из репозитория Remi — например `php83-php-fpm`.
Чтобы не гадать, выведите список служб: `systemctl list-units --type=service | grep -i fpm`. Если на сервере установлено несколько версий PHP, вы увидите все. Перезапускать нужно ту, которую использует ваш сайт: её сокет указан в конфигурации nginx в директиве `fastcgi_pass`.
Все команды управления службами выполняются от имени root или через `sudo`. Без прав суперпользователя systemd попросит пароль или откажет в доступе.
Ubuntu и Debian
sudo systemctl restart php8.2-fpmВерсия PHP входит в имя службы: php7.4-fpm, php8.1-fpm, php8.3-fpm.
CentOS, AlmaLinux, Rocky
sudo systemctl restart php-fpmДля репозитория Remi имя может быть вида php83-php-fpm.
Плавная перезагрузка
sudo systemctl reload php8.2-fpmПрименяет настройки и не обрывает текущие запросы. Основной вариант для рабочего сайта.
Docker Compose
docker compose restart phpЗдесь php — имя сервиса из compose-файла. Для мягкой перезагрузки: docker compose exec php kill -USR2 1.
Restart или reload: что выбрать
Разница между двумя командами принципиальна. Restart останавливает главный процесс php-fpm вместе с воркерами и запускает их заново. Пока служба поднимается, запросы, которые пришли в этот момент, получают ошибку, а выполнявшиеся скрипты прерываются. На небольшом сайте это пара секунд, но на магазине во время оформления заказа этого может хватить, чтобы потерять платёж или заказ.
Reload работает мягче. Служба получает сигнал `USR2`, перечитывает конфигурацию и постепенно заменяет воркеры на новые. Запросы, которые уже выполняются, завершаются штатно. В большинстве дистрибутивов юнит php-fpm настроен так, что `systemctl reload` отправляет именно этот сигнал.
Поэтому на рабочем проекте действуйте по принципу «минимально достаточного вмешательства». Менялись только настройки — делайте reload. Процессы зависли, обновили пакет PHP или reload не помог — тогда restart.
| Команда | Что происходит | Когда использовать |
|---|---|---|
| systemctl reload php8.2-fpm | Мастер-процесс перечитывает конфигурацию и плавно заменяет воркеры | Правки php.ini и пулов на рабочем сайте |
| systemctl restart php8.2-fpm | Служба полностью останавливается и запускается заново | Зависшие процессы, обновление пакета, смена версии PHP |
| systemctl stop + start | То же, что restart, но с паузой между остановкой и запуском | Обслуживание, когда между остановкой и запуском нужно что-то сделать |
| kill -USR2 PID | Ручная отправка сигнала главному процессу php-fpm | Контейнеры и окружения без systemd |
Что происходит внутри при мягкой перезагрузке
Понимание механики помогает не бояться reload на боевом сервере. Главный процесс php-fpm не обрабатывает запросы сам, он только управляет воркерами. Получив сигнал, он аккуратно передаёт работу новым процессам, а старым даёт время закончить начатое.
Время ожидания ограничено директивой `process_control_timeout` в глобальной конфигурации. Если скрипт выполняется дольше, воркер будет остановлен принудительно. Для долгих задач, например генерации больших отчётов, это стоит учитывать.
- 01
Мастер получает сигнал
Команда systemctl reload отправляет главному процессу сигнал USR2.
- 02
Читается новая конфигурация
Проверяются php-fpm.conf, файлы пулов и php.ini. При ошибке в конфиге служба может не подняться, поэтому её нужно проверять заранее.
- 03
Старые воркеры дорабатывают запросы
Текущие запросы завершаются в пределах process_control_timeout.
- 04
Новые воркеры принимают трафик
Пул работает с обновлёнными настройками, а общий кэш OPcache начинается с чистого листа.
Безопасный порядок действий
Опытные администраторы не отправляют команду «вслепую», а проходят короткий чек-лист. Он занимает меньше минуты, но защищает от самой неприятной ситуации: вы перезапустили службу, она не поднялась из-за опечатки в конфигурации, а сайт лежит.
Как перезапустить php-fpm пошагово
- 01
Посмотрите текущее состояние: `sudo systemctl status php8.2-fpm`. Убедитесь, что вы работаете с нужной версией PHP.
- 02
Проверьте синтаксис конфигурации: `sudo php-fpm8.2 -t`. В CentOS и AlmaLinux команда выглядит как `php-fpm -t`. Вы должны увидеть сообщение, что проверка прошла успешно (test is successful).
- 03
Выберите режим. Менялись только настройки — `sudo systemctl reload php8.2-fpm`. Процессы зависли или обновлён пакет — `sudo systemctl restart php8.2-fpm`.
- 04
Убедитесь, что служба в состоянии active (running), а сокет на месте: `ls -l /run/php/`.
- 05
Просмотрите последние строки журнала: `sudo journalctl -u php8.2-fpm -n 50 --no-pager`. Сообщения уровня ERROR и WARNING требуют внимания.
- 06
Проверьте сам сайт: `curl -I https://ваш-сайт.ru` должен вернуть код 200 или ожидаемый 301, а не 502 и 504.
Если перезапуск связан с выкладкой нового кода, делайте его в период минимальной нагрузки. Узнать такое окно проще всего по отчётам посещаемости в Яндекс Метрике или Google Analytics: там видно часы, когда на сайте меньше всего людей.
Отдельно проверьте, не оборвались ли запросы с важными действиями: оплаты, отправки форм, загрузки файлов. Они чаще всего страдают при жёстком restart.
Типичные ошибки при перезапуске php-fpm
Как делать не надо
- Выполнять restart сразу после правки конфигурации, не проверив её командой php-fpm -t.
- Перезапускать службу в час пик на нагруженном магазине или сервисе с онлайн-оплатой.
- Менять путь или права сокета и не обновлять fastcgi_pass в nginx.
- Перезапускать nginx вместо php-fpm и удивляться, что настройки PHP не изменились.
- Не заглядывать в журнал после перезапуска и узнавать о проблеме от клиентов.
Как правильно
- 01
Всегда запускать php-fpm -t до применения изменений.
- 02
Предпочитать reload, а restart оставлять для зависаний и обновлений.
- 03
Выбирать окно с минимальной нагрузкой по статистике Метрики или Analytics.
- 04
Сверять директиву listen в пуле с fastcgi_pass в nginx и права listen.owner и listen.group.
- 05
После перезапуска смотреть systemctl status, журнал и код ответа сайта.
Как проверить, что сайт не пострадал
Успешный статус службы ещё не гарантия, что всё в порядке. Откройте несколько ключевых страниц сайта: главную, карточку товара или статью, корзину, страницу с формой. Убедитесь, что скрипты выполняются, а изображения и стили загружаются.
Для сайтов с поисковым трафиком полезно посмотреть и на реакцию поисковых систем. В Яндекс Вебмастере и Google Search Console следите за разделами с ошибками сервера. Кратковременный всплеск 5xx после перезапуска бывает, но если ошибки держатся, значит, пул не справляется или конфигурация неверна. Поисковые роботы, как Яндекса, так и Google, при частых 5xx снижают скорость обхода сайта, поэтому такие сбои лучше устранять сразу.
- Служба в состоянииactive (running)
- Сокет или порт существует и доступен nginx
- В журнале службы нет строкERROR
- Главная и внутренние страницы отдают код200
- В логе ошибок nginx нет 502 и 504
- В Яндекс Вебмастере и Search Console нет роста 5xx
Что делать, если php-fpm не запускается или сайт отдаёт 502
Если после перезапуска `systemctl status` показывает `failed`, начните с журнала: `sudo journalctl -u php8.2-fpm -n 100 --no-pager`. Почти всегда причина указана прямо там.
Ошибка в конфигурации. Опечатка в имени директивы, лишний символ или дублирующийся пул. Выполните `php-fpm8.2 -t`: команда укажет файл и строку с проблемой.
Занят сокет или порт. Если сообщение говорит, что адрес уже используется, проверьте, не работает ли второй экземпляр php-fpm или другая версия PHP на том же сокете.
Нет прав на сокет. Служба запустилась, но nginx получает ошибку «Permission denied». Убедитесь, что значения `listen.owner` и `listen.group` в пуле совпадают с пользователем, под которым работает nginx (часто `www-data` или `nginx`).
Не совпадают пути. В логе nginx встречается строка вида `connect() to unix:/run/php/php8.2-fpm.sock failed (2: No such file or directory)`. Это значит, что `fastcgi_pass` указывает на сокет, которого нет, например после обновления версии PHP.
Нехватка воркеров. Служба работает, но периодически появляются 502 и 504, а в логе — предупреждение о достижении `pm.max_children`. Перезапуск лишь временно снимет симптом. Нужно увеличить лимит с учётом доступной памяти или оптимизировать медленные скрипты.
Итоги: перезапускайте php-fpm осознанно
- 01
Команда для Ubuntu и Debian: sudo systemctl restart php8.2-fpm, для CentOS и AlmaLinux: sudo systemctl restart php-fpm.
- 02
Для рабочего сайта выбирайте reload: он не обрывает текущие запросы.
- 03
Перед применением всегда выполняйте проверку конфигурации командой php-fpm -t.
- 04
После перезапуска смотрите статус службы, журнал и код ответа сайта.
- 05
Следите за ошибками 5xx в Яндекс Вебмастере и Google Search Console.
Сам по себе перезапуск php-fpm занимает секунды, но от подготовки зависит, пройдёт он незаметно или превратится в аварию. Если проблемы повторяются, пора заняться настройкой пулов, мониторингом и ресурсами сервера.
Часто задаваемые вопросы
В Ubuntu и Debian выполните `sudo systemctl restart php8.2-fpm`, подставив свою версию PHP. В CentOS, AlmaLinux и Rocky Linux служба называется просто `php-fpm`: `sudo systemctl restart php-fpm`.
Reload перечитывает конфигурацию и плавно заменяет рабочие процессы. Текущие запросы при этом успевают завершиться. Restart полностью останавливает службу и запускает её заново, поэтому запросы в этот момент могут оборваться.
Обычно нет. Nginx и php-fpm — независимые службы, и nginx переподключится к сокету или порту php-fpm сам. Перезапуск nginx нужен только при изменении его собственной конфигурации или пути к сокету.
Да. OPcache хранится в общей памяти процессов php-fpm, поэтому и restart, и reload очищают его. Это удобно после выкладки новой версии кода при `opcache.validate_timestamps=0`.
Чаще всего служба не запустилась из-за ошибки в конфигурации или изменился путь либо права сокета. Проверьте `systemctl status`, журнал службы и совпадение директивы `listen` с `fastcgi_pass` в nginx.
Нужна помощь с настройкой сервера и php-fpm? Подключим специалиста
Проверим конфигурацию, пулы и логи, найдём причину 502 и настроим стабильную работу сайта
Спасибо за заявку!
Мы свяжемся с вами в ближайшее время.
502 после перезапуска — частая причина обращений
