Jak zrestartować PHP-FPM: Każda metoda wyjaśniona dla administratorów Linux

PHP-FPM (PHP FastCGI Process Manager) to wysokowydajny menedżer procesów obsługujący wykonywanie PHP jako oddzielną usługę, niezależną od serwera WWW. Ponowne uruchomienie PHP-FPM stosuje zmiany konfiguracji z `php.ini` lub `php-fpm.conf`, odzyskuje wyciekającą pamięć w długo działających pulach procesów roboczych i przywraca działanie nieresponsywnych procesów potomnych — bez dotykania Nginx, Apache ani żadnego innego komponentu stosu.

Ten przewodnik obejmuje wszystkie praktyczne metody ponownego uruchamiania dostępne w nowoczesnych i starszych dystrybucjach Linux, w tym sterowanie oparte na sygnałach, środowiska z wieloma wersjami oraz strategie płynnego przeładowania dla wdrożeń produkcyjnych bez przestojów.

Dlaczego musisz ponownie uruchomić PHP-FPM

Zrozumienie dokładnej przyczyny ponownego uruchomienia zapobiega niepotrzebnym przestojom i pomaga wybrać najmniej destrukcyjną metodę:

• Zmiany konfiguracji: Modyfikacje `php.ini`, `php-fpm.conf` lub dowolnego pliku konfiguracji puli w `/etc/php/<version>/fpm/pool.d/` wymagają ponownego uruchomienia lub przeładowania, aby wejść w życie. PHP-FPM odczytuje te pliki tylko przy uruchomieniu lub po sygnale `USR2`.
• Odzyskiwanie pamięci: Procesy robocze PHP-FPM gromadzą pamięć z czasem, szczególnie na serwerach o dużym ruchu uruchamiających aplikacje intensywnie korzystające z pamięci. Kontrolowane ponowne uruchomienie recykluje procesy robocze i resetuje ich zużycie pamięci.
• Nieresponsywne procesy robocze: Jeśli procesy potomne przejdą w stan zombie lub przestaną akceptować połączenia, ponowne uruchomienie czyści tablicę procesów i tworzy nową pulę.
• Rotacja logów: Po tym, jak `logrotate` zmieni nazwę lub skompresuje aktywny plik logu, PHP-FPM nadal przechowuje deskryptor pliku do starego i-węzła. Przeładowanie wymusza otwarcie nowego deskryptora pliku, zapewniając ciągłość logowania.
• Unieważnienie OPcache: Podczas wdrażania nowego kodu aplikacji ponowne uruchomienie PHP-FPM całkowicie opróżnia OPcache, gwarantując, że procesy robocze wykonują zaktualizowany kod bajtowy, a nie przestarzałe wersje z pamięci podręcznej.
• Zmiany rozszerzeń lub modułów: Dodawanie lub usuwanie rozszerzeń PHP w `php.ini` wymaga pełnego ponownego uruchomienia — samo przeładowanie jest niewystarczające, ponieważ lista rozszerzeń jest oceniana podczas inicjalizacji procesu.

Wymagania wstępne

Przed wykonaniem jakiegokolwiek polecenia ponownego uruchomienia potwierdź następujące kwestie:

• Masz dostęp `root` lub uprawnienia `sudo` na serwerze.
• Znasz dokładną nazwę usługi PHP-FPM w swoim systemie (różni się w zależności od dystrybucji i zainstalowanej wersji).
• Zidentyfikowałeś ścieżkę do pliku PID, jeśli planujesz używać sterowania opartego na sygnałach (zazwyczaj `/run/php/php<version>-fpm.pid` w Debian/Ubuntu lub `/run/php-fpm/php-fpm.pid` w RHEL/CentOS).

Aby odkryć aktywną nazwę usługi PHP-FPM:

“`bash

systemctl list-units –type=service | grep fpm

“`

Aby zlokalizować ścieżkę do pliku PID:

“`bash

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

“`

Metoda 1: Ponowne uruchomienie PHP-FPM za pomocą systemctl (zalecane)

`systemctl` to autorytatywny menedżer usług we wszystkich dystrybucjach opartych na systemd, w tym Ubuntu 16.04+, Debian 8+, CentOS 7+, AlmaLinux, Rocky Linux i Fedora. Jest to właściwe narzędzie dla zdecydowanej większości serwerów produkcyjnych.

Standardowe ponowne uruchomienie

“`bash

sudo systemctl restart php8.2-fpm

“`

Zastąp `php8.2-fpm` wersją zainstalowaną w swoim systemie (np. `php7.4-fpm`, `php8.1-fpm`, `php-fpm`). W systemach opartych na RHEL usługa jest zazwyczaj nazwana `php-fpm` bez prefiksu wersji.

Przeładowanie bez pełnego ponownego uruchomienia

Przeładowanie wysyła wewnętrznie sygnał `USR2`, instruując proces główny, aby ponownie odczytał konfigurację i płynnie zastąpił procesy robocze. Istniejące żądania w trakcie realizacji są kończone przed recyklingiem procesów roboczych:

“`bash

sudo systemctl reload php8.2-fpm

“`

Kluczowa różnica: `reload` jest niezakłócające i preferowane przy zmianach konfiguracji w środowisku produkcyjnym. `restart` natychmiast kończy wszystkie procesy robocze, co może przerywać aktywne połączenia przy dużej współbieżności.

Zatrzymanie i uruchomienie osobno

“`bash

sudo systemctl stop php8.2-fpm

sudo systemctl start php8.2-fpm

“`

Użyj tego dwuetapowego podejścia, gdy musisz potwierdzić, że usługa jest całkowicie zatrzymana przed jej ponownym uruchomieniem — na przykład po zmianie ścieżki gniazda `listen` lub znaczącej modyfikacji `pm.max_children`.

Weryfikacja stanu usługi

“`bash

sudo systemctl status php8.2-fpm

“`

Prawidłowe wyjście pokazuje `Active: active (running)` i wyświetla PID procesu głównego. Jeśli usługa nie uruchomiła się, `systemctl status` wyświetla ostatnie wpisy dziennika, co jest szybsze niż ręczne przeszukiwanie plików logów.

Aby strumieniować logi na żywo podczas ponownego uruchomienia:

“`bash

sudo journalctl -u php8.2-fpm -f

“`

Metoda 2: Ponowne uruchomienie PHP-FPM za pomocą starszego polecenia service

Polecenie `service` jest opakowaniem kompatybilności dla `systemctl` w nowoczesnych systemach i bezpośrednio wywołuje skrypty SysVinit w starszych dystrybucjach (Ubuntu 14.04, CentOS 6, Debian 7). Pozostaje istotne przy zarządzaniu serwerami, które nie zostały zmigrowane do systemd.

“`bash

sudo service php-fpm restart

“`

Aby zatrzymać i uruchomić niezależnie:

“`bash

sudo service php-fpm stop

sudo service php-fpm start

“`

W dystrybucjach nadal używających SysVinit, podstawowy skrypt znajduje się w `/etc/init.d/php-fpm`. Możesz wywołać go bezpośrednio, jeśli opakowanie `service` jest niedostępne:

“`bash

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

“`

Metoda 3: Zarządzanie wieloma wersjami PHP jednocześnie

Serwery z panelami sterowania takimi jak cPanel, Plesk lub niestandardowymi konfiguracjami wielodostępnymi często mają kilka wersji PHP zainstalowanych równolegle. Każda wersja działa jako niezależna usługa PHP-FPM z własnym drzewem konfiguracji, gniazdem i plikiem PID.

Ponowne uruchomienie konkretnej wersji

“`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

“`

Ponowne uruchomienie wszystkich wersji PHP-FPM jednocześnie

Gdy zmiana systemowa dotyczy wszystkich wersji (np. aktualizacja biblioteki współdzielonej), uruchom ponownie wszystkie instancje za pomocą jednej pętli:

“`bash

for ver in 7.4 8.1 8.2; do

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

done

“`

Identyfikacja wersji obsługującej konkretną witrynę

Każdy wirtualny host Nginx lub VirtualHost Apache jest mapowany na konkretne gniazdo PHP-FPM. Sprawdź konfigurację witryny, aby określić, która wersja jest aktywna przed ponownym uruchomieniem:

“`bash

Nginx

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

Apache with mod_proxy_fcgi

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

“`

Jeśli zarządzasz serwerem przez panel sterowania, VPS z cPanel zapewnia graficzny interfejs do przełączania wersji PHP dla każdej domeny bez ręcznego ponownego uruchamiania usług.

Metoda 4: Wysyłanie sygnałów POSIX bezpośrednio do procesu głównego

Proces główny PHP-FPM reaguje na zdefiniowany zestaw sygnałów POSIX. Ta metoda całkowicie omija system init i daje precyzyjną, niskopoziomową kontrolę — niezbędną w środowiskach kontenerowych, niestandardowych systemach init lub gdy `systemctl` jest niedostępny.

Tabela referencyjna sygnałów

Przeładowanie konfiguracji (zero przestojów)

“`bash

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

“`

Jest to funkcjonalnie równoważne `systemctl reload` i jest najbezpieczniejszym sposobem stosowania zmian `php-fpm.conf` lub konfiguracji puli na działającym serwerze.

Ponowne otwarcie plików logów po rotacji

“`bash

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

“`

Uruchom to natychmiast po wykonaniu `logrotate`, aby zapobiec dalszemu zapisywaniu przez PHP-FPM do przemianowanego pliku logu.

Płynne zamknięcie

“`bash

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

“`

Proces główny przestaje akceptować nowe połączenia i czeka, aż wszystkie aktywne procesy robocze zakończą swoje bieżące żądania przed wyjściem. Następnie użyj `sudo systemctl start php8.2-fpm`, aby przywrócić usługę.

Ważne: Zawsze weryfikuj ścieżkę do pliku PID przed użyciem tych poleceń. Nieprawidłowa ścieżka skutkuje wysłaniem sygnału do niezwiązanego procesu. Potwierdź za pomocą:

“`bash

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

ps aux | grep php-fpm

“`

Metoda 5: Wymuszone zabijanie procesów PHP-FPM za pomocą pkill lub killall

Jest to metoda ostateczna w sytuacjach, gdy PHP-FPM stał się całkowicie nieresponsywny, a ani `systemctl`, ani sterowanie oparte na sygnałach nie przynosi rezultatów. Bezwarunkowo kończy wszystkie procesy PHP-FPM, co przerwie wszelkie żądania w trakcie realizacji.

“`bash

sudo pkill -9 php-fpm

“`

Lub używając `killall`:

“`bash

sudo killall -9 php-fpm

“`

Po wymuszonym zabicu usługa nie uruchomi się automatycznie, chyba że jest zarządzana przez nadzorcę procesów. Uruchom ją jawnie:

“`bash

sudo systemctl start php8.2-fpm

“`

Kiedy używać tej metody: Nagromadzenie procesów zombie, niekontrolowane procesy potomne zużywające 100% CPU lub sytuacje, gdy proces główny żyje, ale nie zarządza już swoją pulą. Przed sięgnięciem po `pkill -9`, najpierw spróbuj `kill -QUIT` na PID procesu głównego — jest to znacznie mniej destrukcyjne.

Metoda 6: Ponowne uruchomienie serwera WWW w celu pośredniego wpływu na PHP-FPM

Ponowne uruchomienie Nginx lub Apache nie uruchamia ponownie PHP-FPM. Ponieważ PHP-FPM działa jako całkowicie niezależna usługa komunikująca się przez gniazdo Unix lub port TCP, ponowne uruchomienie serwera WWW wpływa tylko na warstwę HTTP. Jest to powszechne nieporozumienie.

“`bash

Nginx

sudo systemctl restart nginx

Apache

sudo systemctl restart apache2

“`

Jedynym scenariuszem, w którym ponowne uruchomienie serwera WWW jest istotne dla PHP-FPM, jest sytuacja, gdy zmodyfikowałeś dyrektywę `fastcgi_pass` w Nginx lub regułę `ProxyPassMatch` w Apache, aby wskazywała na inne gniazdo PHP-FPM. W takim przypadku Nginx musi przeładować swoją konfigurację, aby połączyć się z nową ścieżką gniazda — ale sam PHP-FPM nadal wymaga własnego oddzielnego ponownego uruchomienia.

W przypadku pełnej konserwacji stosu uruchom ponownie obie usługi w odpowiedniej kolejności: najpierw PHP-FPM, a następnie serwer WWW.

Porównanie: Metody ponownego uruchamiania PHP-FPM w skrócie

Konfiguracja puli PHP-FPM: Co wymaga ponownego uruchomienia, a co przeładowania

Nie wszystkie zmiany konfiguracji mają takie samo znaczenie. Wiedza o tym, które zmiany wymagają pełnego ponownego uruchomienia, a które prostego przeładowania, zmniejsza niepotrzebne przestoje:

Przeładowanie (`USR2` / `systemctl reload`) jest wystarczające dla:

• `pm.max_children`, `pm.start_servers`, `pm.min_spare_servers`, `pm.max_spare_servers`
• `request_terminate_timeout`, `request_slowlog_timeout`
• Zmiany ścieżki `slowlog`
• Dyrektywy `php_admin_value` i `php_flag` w plikach puli
• Zmiany ścieżki `access.log`

Pełne ponowne uruchomienie wymagane dla:

• Zmian dyrektywy `listen` (ścieżka gniazda lub port TCP)
• Dodawania lub usuwania rozszerzeń PHP w `php.ini`
• Zmiany dyrektyw `user` lub `group` w puli
• Modyfikacji ścieżek `include` w `php-fpm.conf`
• Aktualizacji samego pliku binarnego PHP (aktualizacje wersji)

Najlepsze praktyki dla produkcyjnych ponownych uruchomień PHP-FPM

• Zawsze preferuj `reload` zamiast `restart` na działających serwerach. Przeładowanie recykluje procesy robocze płynnie, kończąc żądania w trakcie realizacji przed tworzeniem zamienników. Twarde ponowne uruchomienie natychmiast przerywa wszystkie aktywne połączenia.
• Weryfikuj konfigurację przed przeładowaniem. PHP-FPM zapewnia wbudowane sprawdzanie składni, które zapobiega ładowaniu uszkodzonej konfiguracji:

“`bash

sudo php-fpm8.2 -t

Expected output: NOTICE: configuration file … test is successful

“`

• Sprawdzaj logi przed i po. Przejrzyj `/var/log/php8.2-fpm.log` (lub ścieżkę zdefiniowaną w `php-fpm.conf`) pod kątem wpisów `WARNING` lub `ERROR` wskazujących na błędy uruchamiania puli.
• Monitoruj metryki puli procesów roboczych po ponownym uruchomieniu. Użyj strony statusu PHP-FPM (włączonej przez `pm.status_path` w konfiguracji puli), aby zweryfikować, że oczekiwana liczba procesów roboczych jest aktywna i bezczynna po ponownym uruchomieniu.
• Automatyzuj za pomocą potoków wdrożeniowych. W przepływach pracy CI/CD wyzwalaj `systemctl reload php-fpm` jako hook po wdrożeniu, a nie pełne ponowne uruchomienie. Zapewnia to wdrożenia bez przestojów przy każdym wypchnięciu kodu.
• Ustaw `pm.max_requests` do automatycznego recyklingu procesów roboczych. Zamiast planować okresowe ponowne uruchomienia w celu zwalczania wycieków pamięci, skonfiguruj `pm.max_requests = 500` (lub odpowiednią wartość), aby automatycznie restartować każdy proces roboczy po obsłużeniu określonej liczby żądań.

PHP-FPM w środowiskach VPS i serwerów dedykowanych

Metoda ponownego uruchomienia, której używasz, zależy również od środowiska hostingowego. W planie Hosting VPS z pełnym dostępem root wszystkie metody opisane w tym przewodniku są dostępne bez ograniczeń. Masz bezpośredni dostęp do `systemctl`, pliku PID i tablicy procesów.

Na Serwerach Dedykowanych, gdzie kontrolujesz cały stos sprzętowy, możesz dodatkowo skonfigurować PHP-FPM z `pm = ondemand` lub `pm = dynamic` w celu precyzyjnego dostrojenia zachowania tworzenia procesów roboczych oraz używać plików drop-in `systemd` do dostosowywania polityk ponownego uruchamiania (np. `Restart=on-failure`, `RestartSec=5s`).

Jeśli zarządzasz wieloma witrynami klientów przez rozwiązanie Paneli Sterowania VPS, operacje ponownego uruchamiania PHP-FPM są często abstrakcyjnie przedstawione w interfejsie panelu, ale zrozumienie podstawowych poleceń pozostaje niezbędne w scenariuszach rozwiązywania problemów, gdy sam panel jest nieresponsywny.

W przypadku aplikacji wymagających wysokiej współbieżności PHP — takich jak Laravel, WordPress multisite lub sklepy WooCommerce — połączenie PHP-FPM z odpowiednio dostrojoną konfiguracją puli na Serwerze Dedykowanym eliminuje rywalizację o zasoby, którą wprowadzają środowiska współdzielone.

Macierz decyzyjna: Wybór właściwej metody ponownego uruchomienia

Użyj tej macierzy, aby wybrać właściwe podejście na podstawie swojej konkretnej sytuacji:

FAQ

Jaka jest różnica między `systemctl restart` a `systemctl reload` dla PHP-FPM?

`restart` natychmiast kończy wszystkie procesy główne i robocze i uruchamia od nowa, przerywając wszelkie żądania w trakcie realizacji. `reload` wysyła sygnał `USR2` do procesu głównego, który tworzy nowe procesy robocze ze zaktualizowaną konfiguracją, podczas gdy istniejące procesy robocze kończą swoje bieżące żądania przed wyjściem. Zawsze używaj `reload` w środowisku produkcyjnym.

Jak znaleźć właściwą nazwę usługi PHP-FPM na moim serwerze?

Uruchom `systemctl list-units –type=service | grep fpm`. W systemach Debian/Ubuntu z wieloma wersjami z PPA `ondrej/php` zobaczysz wpisy takie jak `php7.4-fpm.service` i `php8.2-fpm.service`. W RHEL/CentOS z repozytorium Remi konwencja nazewnictwa to `php74-php-fpm.service`.

Czy ponowne uruchomienie PHP-FPM wpływa na aktywne połączenia z bazą danych lub sesje użytkowników?

Twarde ponowne uruchomienie (`systemctl restart`) natychmiast kończy wszystkie procesy robocze, co zamyka wszelkie trwałe połączenia z bazą danych przechowywane przez te procesy. Sesje użytkowników przechowywane w plikach lub bazie danych nie są dotknięte, ponieważ utrzymują się niezależnie od procesów roboczych PHP-FPM. Płynne przeładowanie (`systemctl reload`) pozwala procesom roboczym zakończyć bieżące żądania, więc trwałe połączenia są zamykane czysto.

Dlaczego PHP-FPM nie uruchamia się po ponownym uruchomieniu?

Najczęstsze przyczyny to błąd składni w `php.ini` lub pliku konfiguracji puli, konflikt portu lub ścieżki gniazda (inny proces już nasłuchuje na skonfigurowanym adresie `listen`) lub niewystarczające uprawnienia do katalogu gniazda. Uruchom `php-fpm<ver> -t`, aby zweryfikować składnię konfiguracji, i sprawdź `journalctl -u php<ver>-fpm` w celu uzyskania dokładnego komunikatu o błędzie.

Czy mogę ponownie uruchomić PHP-FPM bez uprawnień root lub sudo?

Nie w standardowej instalacji Linux. Proces główny PHP-FPM działa jako root (obniża uprawnienia do skonfigurowanego `user`/`group` dla procesów roboczych), a zarządzanie usługami systemowymi wymaga podwyższonych uprawnień. W środowiskach hostingu współdzielonego dostawca hostingu obsługuje ponowne uruchomienia PHP-FPM przez swój panel sterowania. Dla pełnej kontroli nad PHP-FPM, plan Hosting VPS z dostępem root jest odpowiednim rozwiązaniem.