Як перезапустити PHP-FPM: усі методи, пояснені для адміністраторів Linux

PHP-FPM (PHP FastCGI Process Manager) — це високопродуктивний менеджер процесів, який обробляє виконання PHP як окремий сервіс, відокремлений від веб-сервера. Перезапуск PHP-FPM застосовує зміни конфігурації з `php.ini` або `php-fpm.conf`, звільняє витоки пам’яті в тривалих пулах воркерів та відновлює роботу після зависання дочірніх процесів — без жодного втручання в Nginx, Apache або будь-який інший компонент вашого стека.

Цей посібник охоплює всі практичні методи перезапуску, доступні в сучасних і застарілих дистрибутивах Linux, включаючи керування на основі сигналів, середовища з кількома версіями та стратегії плавного перезавантаження для розгортань у продакшені без простоїв.

Навіщо потрібно перезапускати PHP-FPM

Розуміння точної причини перезапуску запобігає непотрібним простоям і допомагає вибрати найменш руйнівний метод:

• Зміни конфігурації: Зміни в `php.ini`, `php-fpm.conf` або будь-якому файлі конфігурації пулу в `/etc/php/<version>/fpm/pool.d/` вимагають перезапуску або перезавантаження для набрання чинності. PHP-FPM читає ці файли лише під час запуску або за сигналом `USR2`.
• Звільнення пам’яті: Воркер-процеси PHP-FPM накопичують пам’ять з часом, особливо на серверах з високим трафіком, що запускають ресурсомісткі застосунки. Контрольований перезапуск перезапускає воркери та скидає їх обсяг використання пам’яті.
• Зависання воркерів: Якщо дочірні процеси переходять у стан зомбі або перестають приймати з’єднання, перезапуск очищає таблицю процесів і запускає новий пул.
• Ротація журналів: Після того як `logrotate` перейменовує або стискає активний файл журналу, PHP-FPM все ще утримує файловий дескриптор старого inode. Перезавантаження змушує його відкрити новий файловий дескриптор, забезпечуючи безперервність журналювання.
• Інвалідація OPcache: При розгортанні нового коду застосунку перезапуск PHP-FPM повністю очищає OPcache, гарантуючи, що воркери виконують оновлений байткод, а не застарілі кешовані версії.
• Зміни розширень або модулів: Додавання або видалення PHP-розширень у `php.ini` вимагає повного перезапуску — одного лише перезавантаження недостатньо, оскільки список розширень обчислюється під час ініціалізації процесу.

Передумови

Перед виконанням будь-якої команди перезапуску переконайтеся в наступному:

• Ви маєте доступ `root` або привілеї `sudo` на сервері.
• Ви знаєте точну назву сервісу PHP-FPM у вашій системі (вона відрізняється залежно від дистрибутива та встановленої версії).
• Ви визначили шлях до PID-файлу, якщо плануєте використовувати керування на основі сигналів (зазвичай `/run/php/php<version>-fpm.pid` на Debian/Ubuntu або `/run/php-fpm/php-fpm.pid` на RHEL/CentOS).

Щоб дізнатися назву активного сервісу PHP-FPM:

“`bash

systemctl list-units –type=service | grep fpm

“`

Щоб знайти шлях до PID-файлу:

“`bash

grep -i pid /etc/php/*/fpm/php-fpm.conf

“`

Метод 1: Перезапуск PHP-FPM за допомогою systemctl (рекомендовано)

`systemctl` є авторитетним менеджером сервісів у всіх дистрибутивах на основі systemd, включаючи Ubuntu 16.04+, Debian 8+, CentOS 7+, AlmaLinux, Rocky Linux та Fedora. Це правильний інструмент для переважної більшості продакшен-серверів.

Стандартний перезапуск

“`bash

sudo systemctl restart php8.2-fpm

“`

Замініть `php8.2-fpm` на версію, встановлену у вашій системі (наприклад, `php7.4-fpm`, `php8.1-fpm`, `php-fpm`). На системах на основі RHEL сервіс зазвичай називається `php-fpm` без префікса версії.

Перезавантаження без повного перезапуску

Перезавантаження надсилає сигнал `USR2` внутрішньо, інструктуючи головний процес повторно прочитати конфігурацію та плавно замінити воркер-процеси. Поточні запити, що виконуються, завершуються до того, як воркери будуть перезапущені:

“`bash

sudo systemctl reload php8.2-fpm

“`

Критична відмінність: `reload` є ненав’язливим і кращим для змін конфігурації в продакшені. `restart` негайно завершує всі воркери, що може призвести до втрати активних з’єднань при високому рівні паралелізму.

Зупинка та запуск окремо

“`bash

sudo systemctl stop php8.2-fpm

sudo systemctl start php8.2-fpm

“`

Використовуйте цей двоетапний підхід, коли потрібно переконатися, що сервіс повністю зупинений перед повторним запуском — наприклад, після зміни шляху сокета `listen` або значних змін у `pm.max_children`.

Перевірка стану сервісу

“`bash

sudo systemctl status php8.2-fpm

“`

Справний вивід показує `Active: active (running)` та відображає PID головного процесу. Якщо сервіс не вдалося запустити, `systemctl status` відображає останні записи журналу, що швидше, ніж ручний пошук у файлах журналів.

Для потокового перегляду журналів під час перезапуску:

“`bash

sudo journalctl -u php8.2-fpm -f

“`

Метод 2: Перезапуск PHP-FPM за допомогою застарілої команди service

Команда `service` є оберткою сумісності навколо `systemctl` на сучасних системах і безпосередньо викликає скрипти SysVinit на старіших дистрибутивах (Ubuntu 14.04, CentOS 6, Debian 7). Вона залишається актуальною при управлінні серверами, які не були перенесені на systemd.

“`bash

sudo service php-fpm restart

“`

Для незалежної зупинки та запуску:

“`bash

sudo service php-fpm stop

sudo service php-fpm start

“`

На дистрибутивах, що все ще використовують SysVinit, базовий скрипт розташований за адресою `/etc/init.d/php-fpm`. Ви можете викликати його безпосередньо, якщо обгортка `service` недоступна:

“`bash

sudo /etc/init.d/php-fpm restart

“`

Метод 3: Управління кількома версіями PHP одночасно

Сервери, що запускають панелі керування, такі як cPanel, Plesk, або власні мультиорендні налаштування, часто мають кілька версій PHP, встановлених паралельно. Кожна версія працює як незалежний сервіс PHP-FPM зі своїм деревом конфігурації, сокетом та PID-файлом.

Перезапуск конкретної версії

“`bash

Debian/Ubuntu (packages from ondrej/php PPA or distribution repos)

sudo systemctl restart php7.4-fpm

sudo systemctl restart php8.1-fpm

sudo systemctl restart php8.2-fpm

RHEL/CentOS with Remi repository

sudo systemctl restart php74-php-fpm

sudo systemctl restart php81-php-fpm

“`

Перезапуск усіх версій PHP-FPM одночасно

Коли загальносистемна зміна стосується всіх версій (наприклад, оновлення спільної бібліотеки), перезапустіть усі екземпляри за допомогою одного циклу:

“`bash

for ver in 7.4 8.1 8.2; do

sudo systemctl restart php${ver}-fpm && echo "php${ver}-fpm restarted"

done

“`

Визначення версії, що обслуговує конкретний сайт

Кожен віртуальний хост Nginx або VirtualHost Apache відображається на конкретний сокет PHP-FPM. Перевірте конфігурацію сайту, щоб визначити, яка версія активна перед перезапуском:

“`bash

Nginx

grep fastcgi_pass /etc/nginx/sites-enabled/yourdomain.conf

Apache with mod_proxy_fcgi

grep SetHandler /etc/apache2/sites-enabled/yourdomain.conf

“`

Якщо ви керуєте сервером через панель керування, VPS з cPanel надає графічний інтерфейс для перемикання версій PHP для кожного домену без ручних перезапусків сервісу.

Метод 4: Надсилання сигналів POSIX безпосередньо до головного процесу

Головний процес PHP-FPM реагує на визначений набір сигналів POSIX. Цей метод повністю обходить систему ініціалізації та надає точний низькорівневий контроль — необхідний у контейнеризованих середовищах, власних системах ініціалізації або коли `systemctl` недоступний.

Таблиця довідника сигналів

Перезавантаження конфігурації (без простою)

“`bash

sudo kill -USR2 $(cat /run/php/php8.2-fpm.pid)

“`

Це функціонально еквівалентно `systemctl reload` і є найбезпечнішим способом застосування змін `php-fpm.conf` або конфігурації пулу на живому сервері.

Повторне відкриття файлів журналів після ротації

“`bash

sudo kill -USR1 $(cat /run/php/php8.2-fpm.pid)

“`

Запустіть це відразу після виконання `logrotate`, щоб запобігти продовженню запису PHP-FPM у перейменований файл журналу.

Плавне завершення

“`bash

sudo kill -QUIT $(cat /run/php/php8.2-fpm.pid)

“`

Головний процес припиняє приймати нові з’єднання та очікує завершення поточних запитів усіма активними воркерами перед виходом. Після цього виконайте `sudo systemctl start php8.2-fpm`, щоб відновити роботу сервісу.

Важливо: Завжди перевіряйте шлях до PID-файлу перед використанням цих команд. Неправильний шлях призведе до надсилання сигналу непов’язаному процесу. Підтвердіть за допомогою:

“`bash

cat /run/php/php8.2-fpm.pid

ps aux | grep php-fpm

“`

Метод 5: Примусове завершення процесів PHP-FPM за допомогою pkill або killall

Це крайній захід для ситуацій, коли PHP-FPM повністю перестав відповідати і ні `systemctl`, ні керування на основі сигналів не дають результату. Він безумовно завершує всі процеси PHP-FPM, що перерве будь-які запити, що виконуються.

“`bash

sudo pkill -9 php-fpm

“`

Або за допомогою `killall`:

“`bash

sudo killall -9 php-fpm

“`

Після примусового завершення сервіс не перезапуститься автоматично, якщо він не керується супервізором процесів. Запустіть його явно:

“`bash

sudo systemctl start php8.2-fpm

“`

Коли використовувати: Накопичення зомбі-процесів, некеровані дочірні процеси, що споживають 100% CPU, або ситуації, коли головний процес живий, але більше не керує своїм пулом. Перш ніж вдаватися до `pkill -9`, спробуйте `kill -QUIT` на PID головного процесу — це набагато менш руйнівно.

Метод 6: Перезапуск веб-сервера для непрямого впливу на PHP-FPM

Перезапуск Nginx або Apache не перезапускає PHP-FPM. Оскільки PHP-FPM працює як повністю незалежний сервіс, що спілкується через Unix-сокет або TCP-порт, перезапуск веб-сервера впливає лише на HTTP-рівень. Це поширена хибна думка.

“`bash

Nginx

sudo systemctl restart nginx

Apache

sudo systemctl restart apache2

“`

Єдиний сценарій, коли перезапуск веб-сервера стосується PHP-FPM, — це коли ви змінили директиву `fastcgi_pass` в Nginx або правило `ProxyPassMatch` в Apache, щоб вказати на інший сокет PHP-FPM. У цьому випадку Nginx повинен перезавантажити свою конфігурацію для підключення до нового шляху сокета — але сам PHP-FPM все одно потребує власного окремого перезапуску.

Для повного технічного обслуговування стека перезапустіть обидва сервіси у правильному порядку: спочатку PHP-FPM, потім веб-сервер.

Порівняння: методи перезапуску PHP-FPM на перший погляд

Конфігурація пулу PHP-FPM: що вимагає перезапуску, а що — перезавантаження

Не всі зміни конфігурації мають однакову вагу. Знання того, які зміни вимагають повного перезапуску, а які — простого перезавантаження, зменшує непотрібні простої:

Перезавантаження (`USR2` / `systemctl reload`) достатньо для:

• `pm.max_children`, `pm.start_servers`, `pm.min_spare_servers`, `pm.max_spare_servers`
• `request_terminate_timeout`, `request_slowlog_timeout`
• Зміни шляху `slowlog`
• Директиви `php_admin_value` та `php_flag` у файлах пулу
• Зміни шляху `access.log`

Повний перезапуск необхідний для:

• Змін директиви `listen` (шлях сокета або TCP-порт)
• Додавання або видалення PHP-розширень у `php.ini`
• Зміни директив `user` або `group` у пулі
• Зміни шляхів `include` у `php-fpm.conf`
• Оновлення самого бінарного файлу PHP (оновлення версії)

Найкращі практики для перезапусків PHP-FPM у продакшені

• Завжди надавайте перевагу `reload` над `restart` на живих серверах. Перезавантаження плавно перезапускає воркери, завершуючи запити, що виконуються, перед запуском замінників. Жорсткий перезапуск негайно скидає всі активні з’єднання.
• Перевіряйте конфігурацію перед перезавантаженням. PHP-FPM надає вбудовану перевірку синтаксису, що запобігає завантаженню пошкодженої конфігурації:

“`bash

sudo php-fpm8.2 -t

Expected output: NOTICE: configuration file … test is successful

“`

• Перевіряйте журнали до і після. Переглядайте `/var/log/php8.2-fpm.log` (або шлях, визначений у вашому `php-fpm.conf`) на наявність записів `WARNING` або `ERROR`, що вказують на збої запуску пулу.
• Відстежуйте метрики пулу воркерів після перезапуску. Використовуйте сторінку статусу PHP-FPM (увімкнену через `pm.status_path` у конфігурації пулу), щоб переконатися, що очікувана кількість воркерів активна та в режимі очікування після перезапуску.
• Автоматизуйте за допомогою конвеєрів розгортання. У робочих процесах CI/CD запускайте `systemctl reload php-fpm` як хук після розгортання, а не повний перезапуск. Це забезпечує розгортання без простоїв при кожному push коду.
• Встановіть `pm.max_requests` для автоматичного перезапуску воркерів. Замість планування періодичних перезапусків для боротьби з витоками пам’яті, налаштуйте `pm.max_requests = 500` (або відповідне значення) для автоматичного перезапуску кожного воркера після обробки фіксованої кількості запитів.

PHP-FPM у середовищах VPS та виділених серверів

Метод перезапуску, який ви використовуєте, також залежить від вашого хостингового середовища. На плані VPS Хостингу з повним root-доступом усі методи, описані в цьому посібнику, доступні без обмежень. Ви маєте прямий доступ до `systemctl`, PID-файлу та таблиці процесів.

На Виділених серверах, де ви контролюєте весь апаратний стек, ви також можете налаштувати PHP-FPM з `pm = ondemand` або `pm = dynamic` для точного налаштування поведінки запуску воркерів, а також використовувати drop-in файли `systemd` для налаштування політик перезапуску (наприклад, `Restart=on-failure`, `RestartSec=5s`).

Якщо ви керуєте кількома клієнтськими сайтами через рішення Панелей керування VPS, операції перезапуску PHP-FPM часто абстраговані в інтерфейс панелі, але розуміння базових команд залишається необхідним для сценаріїв усунення несправностей, коли сама панель не відповідає.

Для застосунків, що вимагають високого паралелізму PHP — таких як Laravel, WordPress multisite або магазини WooCommerce — поєднання PHP-FPM з належно налаштованою конфігурацією пулу на Виділеному сервері усуває конкуренцію за ресурси, яку вносять спільні середовища.

Матриця технічних рішень: вибір правильного методу перезапуску

Використовуйте цю матрицю для вибору правильного підходу залежно від вашої конкретної ситуації:

Часті запитання

У чому різниця між `systemctl restart` та `systemctl reload` для PHP-FPM?

`restart` негайно завершує всі головні та воркер-процеси і запускає їх заново, скидаючи будь-які запити, що виконуються. `reload` надсилає сигнал `USR2` головному процесу, який запускає нові воркери з оновленою конфігурацією, поки існуючі воркери завершують свої поточні запити перед виходом. Завжди використовуйте `reload` у продакшені.

Як знайти правильну назву сервісу PHP-FPM на моєму сервері?

Виконайте `systemctl list-units –type=service | grep fpm`. На системах Debian/Ubuntu з кількома версіями з PPA `ondrej/php` ви побачите записи на кшталт `php7.4-fpm.service` та `php8.2-fpm.service`. На RHEL/CentOS з репозиторієм Remi угода про іменування — `php74-php-fpm.service`.

Чи впливає перезапуск PHP-FPM на активні з’єднання з базою даних або сесії користувачів?

Жорсткий перезапуск (`systemctl restart`) негайно завершує всі воркер-процеси, що закриває будь-які постійні з’єднання з базою даних, що утримуються цими воркерами. Сесії користувачів, збережені у файлах або базі даних, не зачіпаються, оскільки вони зберігаються незалежно від воркерів PHP-FPM. Плавне перезавантаження (`systemctl reload`) дозволяє воркерам завершити поточні запити, тому постійні з’єднання закриваються коректно.

Чому PHP-FPM не вдається запустити після перезапуску?

Найпоширеніші причини — синтаксична помилка в `php.ini` або файлі конфігурації пулу, конфлікт порту або шляху сокета (інший процес вже прослуховує налаштовану адресу `listen`), або недостатні права доступу до каталогу сокета. Виконайте `php-fpm<ver> -t` для перевірки синтаксису конфігурації та перевірте `journalctl -u php<ver>-fpm` для отримання точного повідомлення про помилку.

Чи можна перезапустити PHP-FPM без root або sudo привілеїв?

Ні, на стандартній установці Linux. Головний процес PHP-FPM працює від імені root (він знижує привілеї до налаштованих `user`/`group` для воркер-процесів), а управління системними сервісами вимагає підвищених привілеїв. У середовищах спільного хостингу хостинг-провайдер обробляє перезапуски PHP-FPM через свою панель керування. Для повного контролю над PHP-FPM план VPS Хостингу з root-доступом є відповідним рішенням.