PHP-FPM Linux, PHP-FPM (версия уточняется)

PHP-FPM: PHP-FPM перестаёт принимать новые запросы после сбоя дочернего процесса

  • Обновлено
  • Чтение ≈ 3 минуты
  • Нужны права администратора

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

Отдельный сбой дочернего процесса PHP-FPM не должен сам по себе навсегда остановить весь пул: управляющий процесс обычно создаёт нового обработчика. Если новые запросы перестали приниматься, нужно выяснить, жив ли master, возможен ли запуск детей и доступны ли сокет, память и лимиты ОС.

В этой статье
  1. Что происходит и когда применима инструкция
  2. Причины и диагностические признаки
  3. Подробная пошаговая инструкция
  4. Как проверить, что проблема исправлена
  5. Если не помогло — дальнейшая диагностика и откат

#Что происходит и когда применима инструкция

Отдельный сбой дочернего процесса PHP-FPM не должен сам по себе навсегда остановить весь пул: управляющий процесс обычно создаёт нового обработчика. Если новые запросы перестали приниматься, нужно выяснить, жив ли master, возможен ли запуск детей и доступны ли сокет, память и лимиты ОС.

#Причины и диагностические признаки

Возможная причинаКак узнатьЧто делать
Исчерпаны процессы или памятьИсчерпаны процессы или память. Журнал показывает repeated child exit, oom-killer либо невозможность fork.Журнал показывает repeated child exit, oom-killer либо невозможность fork.Изучить OOM, pm.max_children и расход RAM.
Пул перегружен или застыл на ожиданииПул перегружен или застыл на ожидании. Master жив, но active processes исчерпаны, listen queue не уменьшается.Master жив, но active processes исчерпаны, listen queue не уменьшается.Искать медленные запросы, внешние блокировки.
Сокет недоступен веб-серверуСокет недоступен веб-серверу. Nginx возвращает 502 с connect() failed, сокет отсутствует или права изменились.Nginx возвращает 502 с connect() failed, сокет отсутствует или права изменились.Проверить listen и владельца сокета.

#Подробная пошаговая инструкция

  1. Отметьте момент первого сбоя и не запускайте бесконечный restartЕсли сайт уже недоступен, проверьте, отвечает ли статическая страница, и зафиксируйте 502/504. Найдите основную службу php-fpm и количество дочерних процессов; не убивайте все PHP-процессы командой killall.
  2. SSH, только чтение, пример php8.2-fpm
    Linux · Терминал (Bash)Команда
    SSH, только чтение, пример php8.2-fpm. Определите, есть ли master и рабочие процессы пула.
    systemctl is-active php8.2-fpm; ps -eo pid,ppid,rss,args | grep -E "[p]hp-fpm|[p]hp.*fpm"
  1. Прочитайте первичный сбой и ошибки ядраВ journalctl проверьте строки child exited on signal, failed to fork, Terminated, emergency_restart и ошибки регистрации сокета. Сопоставьте со временем OOM в kernel log. Сигнал SIGSEGV в одном расширении требует исправления расширения, а не увеличения тайм-аута.
    Linux · Терминал (Bash)КомандаНужен sudo
    SSH с правами администратора, Linux с systemd. Только чтение; журнал может включать служебные пути.
    sudo journalctl -u php8.2-fpm -n 150 --no-pager; sudo journalctl -k -n 100 --no-pager | grep -Ei "oom|out of memory|killed process"
  1. Проверьте доступность Unix-сокета и параметры пулаНайдите listen в pool.d, затем проверьте наличие сокета, права и соответствие fastcgi_pass/SetHandler в веб-сервере. Если master жив, но все дети заняты, исследуйте медленные запросы и очередь; если сокета нет, смотрите причину неуспешного запуска.
  2. SSH, администратор, только чтение
    Linux · Терминал (Bash)КомандаНужен sudo
    SSH, администратор, только чтение. ss -lxnp показывает Unix-слушателей; синтаксис файла зависит от пакета.
    sudo grep -R -nE "^\s*(\[|listen\s*=|pm.max_children\s*=|pm.max_requests\s*=)" /etc/php/*/fpm/pool.d/*.conf; sudo ss -lxnp | grep -E "php|fpm"
  1. Устраните проверенную причинуЕсли система убивает процессы по OOM, уменьшите пиковое потребление памяти и проверьте лимиты контейнера; если падает расширение, изучите его версию и журнал. Если блокируются внешние вызовы, ограничьте время ожидания в приложении. pm.max_requests может регулярно пересоздавать обработчики, но не лечит каждое аварийное завершение.
  1. Проверяйте конфигурацию перед любым перезапускомПосле резервной копии целевой настройки запустите -t. Только при успешном тесте и понимании последствий перезапустите нужную службу. Если есть несколько рабочих пулов в одном экземпляре FPM, перезапуск затронет их все.
  2. SSH, администратор; restart прерывает обслуживаемые запросы
    Linux · Терминал (Bash)С осторожностьюНужен sudo
    SSH, администратор; restart прерывает обслуживаемые запросы. Пример Debian PHP 8.2, адаптируйте к серверу.
    sudo php-fpm8.2 -t && sudo systemctl restart php8.2-fpm

    Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

  1. Проверьте восстановление и наблюдайте повторяемостьОткройте PHP-страницу сайта, затем проверьте, что число обработчиков стабильно, listen queue разгружается, ошибки child exit не повторяются. Сохраните время теста: повторение после того же сценария указывает на код приложения или модуль.

#Как проверить, что проблема исправлена

Запросы снова обрабатываются, сокет доступен, нет повторных аварий, в журнале отсутствуют новые OOM или ошибки форка.

#Если не помогло — дальнейшая диагностика и откат

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

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

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

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