Wie man PHP-FPM neu startet: Jede Methode erklärt für Linux-Administratoren

PHP-FPM (PHP FastCGI Process Manager) ist ein leistungsstarker Prozessmanager, der die PHP-Ausführung als eigenständigen Dienst übernimmt, entkoppelt vom Webserver. Ein Neustart von PHP-FPM wendet Konfigurationsänderungen aus `php.ini` oder `php-fpm.conf` an, gibt Speicherlecks in lang laufenden Worker-Pools frei und stellt nicht reagierende Child-Prozesse wieder her – ohne Nginx, Apache oder andere Komponenten Ihres Stacks zu berühren.

Dieser Leitfaden behandelt alle praktischen Neustart-Methoden, die auf modernen und älteren Linux-Distributionen verfügbar sind, einschließlich signalbasierter Steuerung, Multi-Versions-Umgebungen und Strategien für graceful Reloads für Zero-Downtime-Produktions-Deployments.

Warum Sie PHP-FPM neu starten müssen

Das genaue Verständnis des Auslösers für einen Neustart verhindert unnötige Ausfallzeiten und hilft Ihnen, die am wenigsten störende Methode zu wählen:

• Konfigurationsänderungen: Änderungen an `php.ini`, `php-fpm.conf` oder einer Pool-Konfigurationsdatei unter `/etc/php/<version>/fpm/pool.d/` erfordern einen Neustart oder Reload, um wirksam zu werden. PHP-FPM liest diese Dateien nur beim Start oder bei einem `USR2`-Signal.
• Speicherrückgewinnung: PHP-FPM-Worker-Prozesse akkumulieren im Laufe der Zeit Speicher, insbesondere auf stark frequentierten Servern, die speicherintensive Anwendungen ausführen. Ein kontrollierter Neustart recycelt Worker und setzt deren Speicher-Footprint zurück.
• Nicht reagierende Worker: Wenn Child-Prozesse in einen Zombie-Zustand geraten oder keine Verbindungen mehr akzeptieren, löscht ein Neustart die Prozesstabelle und startet einen neuen Pool.
• Log-Rotation: Nachdem `logrotate` die aktive Log-Datei umbenennt oder komprimiert, hält PHP-FPM noch einen Dateideskriptor zum alten Inode. Ein Reload zwingt es, den neuen Dateideskriptor zu öffnen und gewährleistet so die Log-Kontinuität.
• OPcache-Invalidierung: Beim Deployment neuen Anwendungscodes leert ein Neustart von PHP-FPM den OPcache vollständig und stellt sicher, dass Worker den aktualisierten Bytecode anstelle veralteter gecachter Versionen ausführen.
• Erweiterungs- oder Moduländerungen: Das Hinzufügen oder Entfernen von PHP-Erweiterungen in `php.ini` erfordert einen vollständigen Neustart – ein Reload allein ist unzureichend, da die Erweiterungsliste bei der Prozessinitialisierung ausgewertet wird.

Voraussetzungen

Bevor Sie einen Neustart-Befehl ausführen, bestätigen Sie Folgendes:

• Sie haben `root`-Zugriff oder `sudo`-Rechte auf dem Server.
• Sie kennen den genauen PHP-FPM-Dienstnamen auf Ihrem System (er variiert je nach Distribution und installierter Version).
• Sie haben den PID-Dateipfad identifiziert, wenn Sie signalbasierte Steuerung verwenden möchten (typischerweise `/run/php/php<version>-fpm.pid` auf Debian/Ubuntu oder `/run/php-fpm/php-fpm.pid` auf RHEL/CentOS).

So ermitteln Sie den aktiven PHP-FPM-Dienstnamen:

“`bash

systemctl list-units –type=service | grep fpm

“`

So finden Sie den PID-Dateipfad:

“`bash

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

“`

Methode 1: PHP-FPM mit systemctl neu starten (Empfohlen)

`systemctl` ist der maßgebliche Dienst-Manager auf allen systemd-basierten Distributionen, einschließlich Ubuntu 16.04+, Debian 8+, CentOS 7+, AlmaLinux, Rocky Linux und Fedora. Es ist das richtige Werkzeug für die überwiegende Mehrheit der Produktionsserver.

Standard-Neustart

“`bash

sudo systemctl restart php8.2-fpm

“`

Ersetzen Sie `php8.2-fpm` durch die auf Ihrem System installierte Version (z. B. `php7.4-fpm`, `php8.1-fpm`, `php-fpm`). Auf RHEL-basierten Systemen heißt der Dienst typischerweise `php-fpm` ohne Versionsprefix.

Reload ohne vollständigen Neustart

Ein Reload sendet intern ein `USR2`-Signal und weist den Master-Prozess an, seine Konfiguration neu zu lesen und Worker-Prozesse graceful zu ersetzen. Laufende Anfragen werden abgeschlossen, bevor Worker recycelt werden:

“`bash

sudo systemctl reload php8.2-fpm

“`

Wichtiger Unterschied: `reload` ist nicht störend und wird für Konfigurationsänderungen in der Produktion bevorzugt. `restart` beendet alle Worker sofort, was bei hoher Parallelität aktive Verbindungen unterbrechen kann.

Separat stoppen und starten

“`bash

sudo systemctl stop php8.2-fpm

sudo systemctl start php8.2-fpm

“`

Verwenden Sie diesen zweistufigen Ansatz, wenn Sie sicherstellen müssen, dass der Dienst vollständig gestoppt ist, bevor Sie ihn wieder starten – zum Beispiel nach dem Ändern des `listen`-Socket-Pfads oder einer wesentlichen Änderung von `pm.max_children`.

Den Dienststatus überprüfen

“`bash

sudo systemctl status php8.2-fpm

“`

Eine fehlerfreie Ausgabe zeigt `Active: active (running)` und listet die Master-PID auf. Wenn der Dienst nicht gestartet werden konnte, zeigt `systemctl status` die letzten Journal-Einträge an, was schneller ist als das manuelle Durchsuchen von Log-Dateien.

So streamen Sie Live-Logs während eines Neustarts:

“`bash

sudo journalctl -u php8.2-fpm -f

“`

Methode 2: PHP-FPM mit dem Legacy-Befehl service neu starten

Der Befehl `service` ist ein Kompatibilitäts-Wrapper um `systemctl` auf modernen Systemen und ruft SysVinit-Skripte direkt auf älteren Distributionen auf (Ubuntu 14.04, CentOS 6, Debian 7). Er bleibt relevant bei der Verwaltung von Servern, die noch nicht auf systemd migriert wurden.

“`bash

sudo service php-fpm restart

“`

Um unabhängig zu stoppen und zu starten:

“`bash

sudo service php-fpm stop

sudo service php-fpm start

“`

Auf Distributionen, die noch SysVinit verwenden, befindet sich das zugrunde liegende Skript unter `/etc/init.d/php-fpm`. Sie können es direkt aufrufen, wenn der `service`-Wrapper nicht verfügbar ist:

“`bash

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

“`

Methode 3: Mehrere PHP-Versionen gleichzeitig verwalten

Server, auf denen Control Panels wie cPanel, Plesk oder benutzerdefinierte Multi-Tenant-Setups laufen, haben häufig mehrere PHP-Versionen parallel installiert. Jede Version läuft als unabhängiger PHP-FPM-Dienst mit eigenem Konfigurationsbaum, Socket und PID-Datei.

Eine bestimmte Version neu starten

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

“`

Alle PHP-FPM-Versionen auf einmal neu starten

Wenn eine systemweite Änderung alle Versionen betrifft (z. B. ein Update einer gemeinsam genutzten Bibliothek), starten Sie alle Instanzen mit einer einzigen Schleife neu:

“`bash

for ver in 7.4 8.1 8.2; do

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

done

“`

Ermitteln, welche Version eine bestimmte Website bedient

Jeder Nginx-Virtual-Host oder Apache-VirtualHost ist einem bestimmten PHP-FPM-Socket zugeordnet. Überprüfen Sie die Site-Konfiguration, um festzustellen, welche Version aktiv ist, bevor Sie neu starten:

“`bash

Nginx

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

Apache with mod_proxy_fcgi

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

“`

Wenn Sie Ihren Server über ein Control Panel verwalten, bietet VPS mit cPanel eine grafische Oberfläche zum Wechseln von PHP-Versionen pro Domain ohne manuelle Dienst-Neustarts.

Methode 4: POSIX-Signale direkt an den Master-Prozess senden

Der Master-Prozess von PHP-FPM reagiert auf einen definierten Satz von POSIX-Signalen. Diese Methode umgeht das Init-System vollständig und gibt Ihnen präzise, niedrigschwellige Kontrolle – unerlässlich in containerisierten Umgebungen, benutzerdefinierten Init-Systemen oder wenn `systemctl` nicht verfügbar ist.

Signal-Referenztabelle

Konfiguration neu laden (Zero Downtime)

“`bash

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

“`

Dies ist funktional äquivalent zu `systemctl reload` und die sicherste Methode, um `php-fpm.conf`- oder Pool-Konfigurationsänderungen auf einem Live-Server anzuwenden.

Log-Dateien nach Rotation erneut öffnen

“`bash

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

“`

Führen Sie dies unmittelbar nach der Ausführung von `logrotate` aus, um zu verhindern, dass PHP-FPM weiterhin in die umbenannte Log-Datei schreibt.

Graceful Shutdown

“`bash

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

“`

Der Master-Prozess akzeptiert keine neuen Verbindungen mehr und wartet, bis alle aktiven Worker ihre aktuellen Anfragen abgeschlossen haben, bevor er beendet wird. Folgen Sie diesem Schritt mit `sudo systemctl start php8.2-fpm`, um den Dienst wieder zu starten.

Wichtig: Überprüfen Sie immer den PID-Dateipfad, bevor Sie diese Befehle verwenden. Ein falscher Pfad führt dazu, dass ein Signal an einen nicht verwandten Prozess gesendet wird. Bestätigen Sie mit:

“`bash

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

ps aux | grep php-fpm

“`

Methode 5: PHP-FPM-Prozesse mit pkill oder killall erzwungen beenden

Dies ist eine Methode des letzten Auswegs für Situationen, in denen PHP-FPM vollständig nicht mehr reagiert und weder `systemctl` noch signalbasierte Steuerung Ergebnisse liefert. Sie beendet alle PHP-FPM-Prozesse bedingungslos, was laufende Anfragen unterbrechen wird.

“`bash

sudo pkill -9 php-fpm

“`

Oder mit `killall`:

“`bash

sudo killall -9 php-fpm

“`

Nach dem erzwungenen Beenden wird der Dienst nicht automatisch neu gestartet, es sei denn, er wird von einem Prozess-Supervisor verwaltet. Starten Sie ihn explizit:

“`bash

sudo systemctl start php8.2-fpm

“`

Wann dies zu verwenden ist: Anhäufung von Zombie-Prozessen, unkontrollierte Child-Prozesse, die 100% CPU verbrauchen, oder Situationen, in denen der Master-Prozess aktiv ist, aber seinen Pool nicht mehr verwaltet. Bevor Sie zu `pkill -9` greifen, versuchen Sie zunächst `kill -QUIT` auf der Master-PID – das ist weitaus weniger störend.

Methode 6: Den Webserver neu starten, um PHP-FPM indirekt zu beeinflussen

Ein Neustart von Nginx oder Apache startet PHP-FPM nicht neu. Da PHP-FPM als vollständig unabhängiger Dienst läuft, der über einen Unix-Socket oder TCP-Port kommuniziert, betrifft der Webserver-Neustart nur die HTTP-Schicht. Dies ist ein weit verbreitetes Missverständnis.

“`bash

Nginx

sudo systemctl restart nginx

Apache

sudo systemctl restart apache2

“`

Das einzige Szenario, in dem ein Webserver-Neustart für PHP-FPM relevant ist, ist, wenn Sie die `fastcgi_pass`-Direktive in Nginx oder die `ProxyPassMatch`-Regel in Apache geändert haben, um auf einen anderen PHP-FPM-Socket zu verweisen. In diesem Fall muss Nginx seine Konfiguration neu laden, um sich mit dem neuen Socket-Pfad zu verbinden – aber PHP-FPM selbst benötigt noch seinen eigenen separaten Neustart.

Für Full-Stack-Wartung starten Sie beide Dienste in der richtigen Reihenfolge neu: zuerst PHP-FPM, dann den Webserver.

Vergleich: PHP-FPM-Neustart-Methoden auf einen Blick

PHP-FPM-Pool-Konfiguration: Was einen Neustart vs. einen Reload erfordert

Nicht alle Konfigurationsänderungen haben das gleiche Gewicht. Zu wissen, welche Änderungen einen vollständigen Neustart gegenüber einem einfachen Reload erfordern, reduziert unnötige Ausfallzeiten:

Reload (`USR2` / `systemctl reload`) ist ausreichend für:

• `pm.max_children`, `pm.start_servers`, `pm.min_spare_servers`, `pm.max_spare_servers`
• `request_terminate_timeout`, `request_slowlog_timeout`
• `slowlog`-Pfadänderungen
• `php_admin_value`- und `php_flag`-Direktiven innerhalb von Pool-Dateien
• `access.log`-Pfadänderungen

Vollständiger Neustart erforderlich für:

• Änderungen an der `listen`-Direktive (Socket-Pfad oder TCP-Port)
• Hinzufügen oder Entfernen von PHP-Erweiterungen in `php.ini`
• Ändern von `user`- oder `group`-Direktiven im Pool
• Ändern von `include`-Pfaden in `php-fpm.conf`
• Aktualisierung des PHP-Binaries selbst (Versions-Upgrades)

Best Practices für PHP-FPM-Neustarts in der Produktion

• Bevorzugen Sie auf Live-Servern immer `reload` gegenüber `restart`. Ein Reload recycelt Worker graceful und schließt laufende Anfragen ab, bevor Ersatz-Worker gestartet werden. Ein harter Neustart unterbricht alle aktiven Verbindungen sofort.
• Konfiguration vor dem Reload validieren. PHP-FPM bietet eine integrierte Syntaxprüfung, die das Laden einer fehlerhaften Konfiguration verhindert:

“`bash

sudo php-fpm8.2 -t

Expected output: NOTICE: configuration file … test is successful

“`

• Logs vor und nach dem Neustart prüfen. Überprüfen Sie `/var/log/php8.2-fpm.log` (oder den in Ihrer `php-fpm.conf` definierten Pfad) auf `WARNING`- oder `ERROR`-Einträge, die auf Pool-Startfehler hinweisen.
• Worker-Pool-Metriken nach dem Neustart überwachen. Verwenden Sie die PHP-FPM-Statusseite (aktiviert über `pm.status_path` in Ihrer Pool-Konfiguration), um zu überprüfen, ob die erwartete Anzahl von Workern nach dem Neustart aktiv und im Leerlauf ist.
• Mit Deployment-Pipelines automatisieren. Lösen Sie in CI/CD-Workflows `systemctl reload php-fpm` als Post-Deploy-Hook aus, anstatt einen vollständigen Neustart durchzuführen. Dies gewährleistet Zero-Downtime-Deployments bei jedem Code-Push.
• `pm.max_requests` für automatisches Worker-Recycling setzen. Anstatt periodische Neustarts zur Bekämpfung von Speicherlecks zu planen, konfigurieren Sie `pm.max_requests = 500` (oder einen geeigneten Wert), um jeden Worker automatisch neu zu starten, nachdem er eine feste Anzahl von Anfragen bedient hat.

PHP-FPM in VPS- und Dedicated-Server-Umgebungen

Die von Ihnen verwendete Neustart-Methode wird auch von Ihrer Hosting-Umgebung beeinflusst. Bei einem VPS Hosting-Plan mit vollem Root-Zugriff stehen alle in diesem Leitfaden beschriebenen Methoden ohne Einschränkungen zur Verfügung. Sie haben direkten Zugriff auf `systemctl`, die PID-Datei und die Prozesstabelle.

Auf Dedicated Servers, wo Sie den gesamten Hardware-Stack kontrollieren, können Sie PHP-FPM zusätzlich mit `pm = ondemand` oder `pm = dynamic` konfigurieren, um das Worker-Spawning-Verhalten präzise abzustimmen, und `systemd`-Drop-in-Dateien verwenden, um Neustart-Richtlinien anzupassen (z. B. `Restart=on-failure`, `RestartSec=5s`).

Wenn Sie mehrere Client-Sites über eine VPS Control Panels-Lösung verwalten, werden PHP-FPM-Neustart-Operationen oft in die Benutzeroberfläche des Panels abstrahiert, aber das Verständnis der zugrunde liegenden Befehle bleibt für Fehlerbehebungsszenarien unerlässlich, in denen das Panel selbst nicht reagiert.

Für Anwendungen, die hohe PHP-Parallelität erfordern – wie Laravel, WordPress Multisite oder WooCommerce-Shops – eliminiert die Kombination von PHP-FPM mit einer ordnungsgemäß abgestimmten Pool-Konfiguration auf einem Dedicated Server den Ressourcenkonflikt, den Shared-Umgebungen mit sich bringen.

Technische Entscheidungsmatrix: Die richtige Neustart-Methode wählen

Verwenden Sie diese Matrix, um den richtigen Ansatz basierend auf Ihrer spezifischen Situation auszuwählen:

FAQ

Was ist der Unterschied zwischen `systemctl restart` und `systemctl reload` für PHP-FPM?

`restart` beendet sofort alle Master- und Worker-Prozesse und startet neu, wobei laufende Anfragen unterbrochen werden. `reload` sendet ein `USR2`-Signal an den Master-Prozess, der neue Worker mit der aktualisierten Konfiguration startet, während bestehende Worker ihre aktuellen Anfragen abschließen, bevor sie beendet werden. Verwenden Sie in der Produktion immer `reload`.

Wie finde ich den korrekten PHP-FPM-Dienstnamen auf meinem Server?

Führen Sie `systemctl list-units –type=service | grep fpm` aus. Auf Debian/Ubuntu-Systemen mit mehreren Versionen aus dem `ondrej/php`-PPA sehen Sie Einträge wie `php7.4-fpm.service` und `php8.2-fpm.service`. Auf RHEL/CentOS mit dem Remi-Repository lautet die Namenskonvention `php74-php-fpm.service`.

Beeinflusst ein Neustart von PHP-FPM aktive Datenbankverbindungen oder Benutzersitzungen?

Ein harter Neustart (`systemctl restart`) beendet alle Worker-Prozesse sofort, was alle von diesen Workern gehaltenen persistenten Datenbankverbindungen schließt. Benutzersitzungen, die in Dateien oder einer Datenbank gespeichert sind, sind nicht betroffen, da sie unabhängig von PHP-FPM-Workern bestehen. Ein graceful Reload (`systemctl reload`) ermöglicht es Workern, ihre aktuellen Anfragen abzuschließen, sodass persistente Verbindungen sauber geschlossen werden.

Warum startet PHP-FPM nach einem Neustart nicht?

Die häufigsten Ursachen sind ein Syntaxfehler in `php.ini` oder einer Pool-Konfigurationsdatei, ein Port- oder Socket-Pfad-Konflikt (ein anderer Prozess lauscht bereits auf der konfigurierten `listen`-Adresse) oder unzureichende Berechtigungen im Socket-Verzeichnis. Führen Sie `php-fpm<ver> -t` aus, um die Konfigurationssyntax zu validieren, und überprüfen Sie `journalctl -u php<ver>-fpm` auf die genaue Fehlermeldung.

Kann ich PHP-FPM ohne Root- oder sudo-Rechte neu starten?

Nicht bei einer Standard-Linux-Installation. Der Master-Prozess von PHP-FPM läuft als Root (er gibt Rechte an den konfigurierten `user`/`group` für Worker-Prozesse ab), und die Verwaltung von Systemdiensten erfordert erhöhte Rechte. In Shared-Hosting-Umgebungen übernimmt der Hosting-Anbieter PHP-FPM-Neustarts über sein Control Panel. Für vollständige Kontrolle über PHP-FPM ist ein VPS Hosting-Plan mit Root-Zugriff die geeignete Lösung.