Comment redémarrer PHP-FPM : Toutes les méthodes expliquées pour les administrateurs Linux

PHP-FPM (PHP FastCGI Process Manager) est un gestionnaire de processus haute performance qui gère l’exécution de PHP en tant que service indépendant, découplé du serveur web. Le redémarrage de PHP-FPM applique les modifications de configuration de `php.ini` ou `php-fpm.conf`, récupère la mémoire perdue dans les pools de workers à longue durée d’exécution, et récupère les processus enfants qui ne répondent plus — le tout sans toucher à Nginx, Apache, ou tout autre composant de votre stack.

Ce guide couvre toutes les méthodes de redémarrage pratiques disponibles sur les distributions Linux modernes et anciennes, notamment le contrôle par signaux, les environnements multi-versions et les stratégies de rechargement progressif pour les déploiements en production sans interruption de service.

Pourquoi redémarrer PHP-FPM

Comprendre le déclencheur exact d’un redémarrage évite les interruptions inutiles et vous aide à choisir la méthode la moins perturbatrice :

• Modifications de configuration : Les modifications apportées à `php.ini`, `php-fpm.conf`, ou tout fichier de configuration de pool sous `/etc/php/<version>/fpm/pool.d/` nécessitent un redémarrage ou un rechargement pour prendre effet. PHP-FPM ne lit ces fichiers qu’au démarrage ou sur un signal `USR2`.
• Récupération de mémoire : Les processus workers de PHP-FPM accumulent de la mémoire au fil du temps, en particulier sur les serveurs à fort trafic exécutant des applications gourmandes en mémoire. Un redémarrage contrôlé recycle les workers et réinitialise leur empreinte mémoire.
• Workers qui ne répondent plus : Si des processus enfants entrent dans un état zombie ou cessent d’accepter des connexions, un redémarrage vide la table des processus et génère un nouveau pool.
• Rotation des logs : Après que `logrotate` renomme ou compresse le fichier de log actif, PHP-FPM conserve toujours un descripteur de fichier pointant vers l’ancien inode. Un rechargement le force à ouvrir le nouveau descripteur de fichier, assurant la continuité des logs.
• Invalidation de l’OPcache : Lors du déploiement d’un nouveau code applicatif, le redémarrage de PHP-FPM vide entièrement l’OPcache, garantissant que les workers exécutent le bytecode mis à jour plutôt que des versions mises en cache obsolètes.
• Modifications d’extensions ou de modules : L’ajout ou la suppression d’extensions PHP dans `php.ini` nécessite un redémarrage complet — un simple rechargement est insuffisant car la liste des extensions est évaluée lors de l’initialisation du processus.

Prérequis

Avant d’exécuter toute commande de redémarrage, vérifiez les points suivants :

• Vous disposez d’un accès `root` ou de privilèges `sudo` sur le serveur.
• Vous connaissez le nom exact du service PHP-FPM sur votre système (il varie selon la distribution et la version installée).
• Vous avez identifié le chemin du fichier PID si vous prévoyez d’utiliser le contrôle par signaux (généralement `/run/php/php<version>-fpm.pid` sur Debian/Ubuntu ou `/run/php-fpm/php-fpm.pid` sur RHEL/CentOS).

Pour découvrir le nom du service PHP-FPM actif :

“`bash

systemctl list-units –type=service | grep fpm

“`

Pour localiser le chemin du fichier PID :

“`bash

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

“`

Méthode 1 : Redémarrer PHP-FPM avec systemctl (Recommandé)

`systemctl` est le gestionnaire de services de référence sur toutes les distributions basées sur systemd, notamment Ubuntu 16.04+, Debian 8+, CentOS 7+, AlmaLinux, Rocky Linux et Fedora. C’est l’outil approprié pour la grande majorité des serveurs en production.

Redémarrage standard

“`bash

sudo systemctl restart php8.2-fpm

“`

Remplacez `php8.2-fpm` par la version installée sur votre système (par ex., `php7.4-fpm`, `php8.1-fpm`, `php-fpm`). Sur les systèmes basés sur RHEL, le service est généralement nommé `php-fpm` sans préfixe de version.

Rechargement sans redémarrage complet

Un rechargement envoie un signal `USR2` en interne, demandant au processus maître de relire sa configuration et de remplacer progressivement les processus workers. Les requêtes en cours sont traitées avant que les workers ne soient recyclés :

“`bash

sudo systemctl reload php8.2-fpm

“`

Distinction essentielle : `reload` est non perturbateur et préférable pour les modifications de configuration en production. `restart` termine immédiatement tous les workers, ce qui peut interrompre les connexions actives en cas de forte concurrence.

Arrêt et démarrage séparés

“`bash

sudo systemctl stop php8.2-fpm

sudo systemctl start php8.2-fpm

“`

Utilisez cette approche en deux étapes lorsque vous devez confirmer que le service est complètement arrêté avant de le relancer — par exemple, après avoir modifié le chemin du socket `listen` ou modifié significativement `pm.max_children`.

Vérifier l’état du service

“`bash

sudo systemctl status php8.2-fpm

“`

Une sortie saine affiche `Active: active (running)` et liste le PID maître. Si le service n’a pas réussi à démarrer, `systemctl status` affiche les dernières entrées du journal, ce qui est plus rapide que de parcourir manuellement les fichiers de log.

Pour diffuser les logs en direct lors d’un redémarrage :

“`bash

sudo journalctl -u php8.2-fpm -f

“`

Méthode 2 : Redémarrer PHP-FPM avec la commande service héritée

La commande `service` est un wrapper de compatibilité autour de `systemctl` sur les systèmes modernes et invoque directement les scripts SysVinit sur les distributions plus anciennes (Ubuntu 14.04, CentOS 6, Debian 7). Elle reste pertinente pour la gestion des serveurs qui n’ont pas été migrés vers systemd.

“`bash

sudo service php-fpm restart

“`

Pour arrêter et démarrer indépendamment :

“`bash

sudo service php-fpm stop

sudo service php-fpm start

“`

Sur les distributions qui utilisent encore SysVinit, le script sous-jacent se trouve à `/etc/init.d/php-fpm`. Vous pouvez l’invoquer directement si le wrapper `service` n’est pas disponible :

“`bash

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

“`

Méthode 3 : Gérer plusieurs versions de PHP simultanément

Les serveurs exécutant des panneaux de contrôle tels que cPanel, Plesk, ou des configurations multi-tenant personnalisées disposent fréquemment de plusieurs versions de PHP installées en parallèle. Chaque version s’exécute en tant que service PHP-FPM indépendant avec sa propre arborescence de configuration, son socket et son fichier PID.

Redémarrer une version spécifique

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

“`

Redémarrer toutes les versions de PHP-FPM en même temps

Lorsqu’une modification à l’échelle du système affecte toutes les versions (comme une mise à jour de bibliothèque partagée), redémarrez toutes les instances avec une seule boucle :

“`bash

for ver in 7.4 8.1 8.2; do

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

done

“`

Identifier quelle version sert un site spécifique

Chaque hôte virtuel Nginx ou VirtualHost Apache est associé à un socket PHP-FPM spécifique. Vérifiez la configuration du site pour déterminer quelle version est active avant de redémarrer :

“`bash

Nginx

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

Apache with mod_proxy_fcgi

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

“`

Si vous gérez votre serveur via un panneau de contrôle, VPS avec cPanel fournit une interface graphique pour changer les versions de PHP par domaine sans redémarrages manuels du service.

Méthode 4 : Envoyer des signaux POSIX directement au processus maître

Le processus maître de PHP-FPM répond à un ensemble défini de signaux POSIX. Cette méthode contourne entièrement le système init et vous donne un contrôle précis de bas niveau — essentiel dans les environnements conteneurisés, les systèmes init personnalisés, ou lorsque `systemctl` n’est pas disponible.

Tableau de référence des signaux

Recharger la configuration (zéro interruption)

“`bash

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

“`

C’est fonctionnellement équivalent à `systemctl reload` et c’est la méthode la plus sûre pour appliquer les modifications de `php-fpm.conf` ou de configuration de pool sur un serveur en production.

Rouvrir les fichiers de log après rotation

“`bash

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

“`

Exécutez cette commande immédiatement après l’exécution de `logrotate` pour empêcher PHP-FPM de continuer à écrire dans le fichier de log renommé.

Arrêt progressif

“`bash

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

“`

Le processus maître cesse d’accepter de nouvelles connexions et attend que tous les workers actifs terminent leurs requêtes en cours avant de quitter. Suivez cela avec `sudo systemctl start php8.2-fpm` pour relancer le service.

Important : Vérifiez toujours le chemin du fichier PID avant d’utiliser ces commandes. Un chemin incorrect entraîne l’envoi d’un signal à un processus sans rapport. Confirmez avec :

“`bash

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

ps aux | grep php-fpm

“`

Méthode 5 : Forcer l’arrêt des processus PHP-FPM avec pkill ou killall

Il s’agit d’une méthode de dernier recours pour les situations où PHP-FPM est devenu complètement non réactif et où ni `systemctl` ni le contrôle par signaux ne produisent de résultats. Elle termine tous les processus PHP-FPM de manière inconditionnelle, ce qui interrompra toutes les requêtes en cours.

“`bash

sudo pkill -9 php-fpm

“`

Ou en utilisant `killall` :

“`bash

sudo killall -9 php-fpm

“`

Après un arrêt forcé, le service ne redémarrera pas automatiquement sauf s’il est géré par un superviseur de processus. Démarrez-le explicitement :

“`bash

sudo systemctl start php8.2-fpm

“`

Quand utiliser cette méthode : Accumulation de processus zombies, processus enfants incontrôlables consommant 100% du CPU, ou situations où le processus maître est actif mais ne gère plus son pool. Avant d’utiliser `pkill -9`, essayez d’abord `kill -QUIT` sur le PID maître — c’est bien moins perturbateur.

Méthode 6 : Redémarrer le serveur web pour affecter indirectement PHP-FPM

Redémarrer Nginx ou Apache ne redémarre pas PHP-FPM. Étant donné que PHP-FPM s’exécute en tant que service complètement indépendant communiquant via un socket Unix ou un port TCP, le redémarrage du serveur web n’affecte que la couche HTTP. C’est une idée reçue courante.

“`bash

Nginx

sudo systemctl restart nginx

Apache

sudo systemctl restart apache2

“`

Le seul scénario où un redémarrage du serveur web est pertinent pour PHP-FPM est lorsque vous avez modifié la directive `fastcgi_pass` dans Nginx ou la règle `ProxyPassMatch` dans Apache pour pointer vers un socket PHP-FPM différent. Dans ce cas, Nginx doit recharger sa configuration pour se connecter au nouveau chemin de socket — mais PHP-FPM lui-même nécessite toujours son propre redémarrage séparé.

Pour une maintenance complète de la stack, redémarrez les deux services dans le bon ordre : PHP-FPM en premier, puis le serveur web.

Comparaison : Les méthodes de redémarrage de PHP-FPM en un coup d’œil

Configuration des pools PHP-FPM : Ce qui nécessite un redémarrage vs. un rechargement

Toutes les modifications de configuration n’ont pas le même poids. Savoir quelles modifications nécessitent un redémarrage complet plutôt qu’un simple rechargement réduit les interruptions inutiles :

Un rechargement (`USR2` / `systemctl reload`) est suffisant pour :

• `pm.max_children`, `pm.start_servers`, `pm.min_spare_servers`, `pm.max_spare_servers`
• `request_terminate_timeout`, `request_slowlog_timeout`
• Les modifications de chemin `slowlog`
• Les directives `php_admin_value` et `php_flag` dans les fichiers de pool
• Les modifications de chemin `access.log`

Un redémarrage complet est requis pour :

• Les modifications de la directive `listen` (chemin du socket ou port TCP)
• L’ajout ou la suppression d’extensions PHP dans `php.ini`
• La modification des directives `user` ou `group` dans le pool
• La modification des chemins `include` dans `php-fpm.conf`
• La mise à jour du binaire PHP lui-même (mises à niveau de version)

Bonnes pratiques pour les redémarrages de PHP-FPM en production

• Préférez toujours `reload` à `restart` sur les serveurs en production. Un rechargement recycle les workers progressivement, complétant les requêtes en cours avant de générer des remplaçants. Un redémarrage brutal interrompt immédiatement toutes les connexions actives.
• Validez la configuration avant de recharger. PHP-FPM fournit une vérification syntaxique intégrée qui empêche le chargement d’une configuration incorrecte :

“`bash

sudo php-fpm8.2 -t

Expected output: NOTICE: configuration file … test is successful

“`

• Vérifiez les logs avant et après. Consultez `/var/log/php8.2-fpm.log` (ou le chemin défini dans votre `php-fpm.conf`) pour les entrées `WARNING` ou `ERROR` qui indiquent des échecs de démarrage du pool.
• Surveillez les métriques du pool de workers après le redémarrage. Utilisez la page de statut PHP-FPM (activée via `pm.status_path` dans votre configuration de pool) pour vérifier que le nombre attendu de workers est actif et inactif après le redémarrage.
• Automatisez avec des pipelines de déploiement. Dans les workflows CI/CD, déclenchez `systemctl reload php-fpm` comme hook post-déploiement plutôt qu’un redémarrage complet. Cela garantit des déploiements sans interruption à chaque push de code.
• Configurez `pm.max_requests` pour recycler automatiquement les workers. Plutôt que de planifier des redémarrages périodiques pour lutter contre les fuites mémoire, configurez `pm.max_requests = 500` (ou une valeur appropriée) pour redémarrer automatiquement chaque worker après avoir traité un nombre fixe de requêtes.

PHP-FPM sur les environnements VPS et serveurs dédiés

La méthode de redémarrage que vous utilisez est également influencée par votre environnement d’hébergement. Sur un plan VPS Hosting avec accès root complet, toutes les méthodes décrites dans ce guide sont disponibles sans restriction. Vous avez un accès direct à `systemctl`, au fichier PID et à la table des processus.

Sur les Serveurs Dédiés, où vous contrôlez l’ensemble de la stack matérielle, vous pouvez également configurer PHP-FPM avec `pm = ondemand` ou `pm = dynamic` pour ajuster précisément le comportement de génération des workers, et utiliser des fichiers drop-in `systemd` pour personnaliser les politiques de redémarrage (par ex., `Restart=on-failure`, `RestartSec=5s`).

Si vous gérez plusieurs sites clients via une solution Panneaux de contrôle VPS, les opérations de redémarrage de PHP-FPM sont souvent abstraites dans l’interface utilisateur du panneau, mais la compréhension des commandes sous-jacentes reste essentielle pour les scénarios de dépannage où le panneau lui-même ne répond plus.

Pour les applications nécessitant une forte concurrence PHP — telles que Laravel, WordPress multisite ou les boutiques WooCommerce — associer PHP-FPM à une configuration de pool correctement ajustée sur un Serveur Dédié élimine la contention de ressources qu’introduisent les environnements partagés.

Matrice de décision technique : Choisir la bonne méthode de redémarrage

Utilisez cette matrice pour sélectionner l’approche correcte en fonction de votre situation spécifique :

FAQ

Quelle est la différence entre `systemctl restart` et `systemctl reload` pour PHP-FPM ?

`restart` termine immédiatement tous les processus maîtres et workers et repart de zéro, abandonnant toutes les requêtes en cours. `reload` envoie un signal `USR2` au processus maître, qui génère de nouveaux workers avec la configuration mise à jour tandis que les workers existants terminent leurs requêtes en cours avant de quitter. Utilisez toujours `reload` en production.

Comment trouver le nom correct du service PHP-FPM sur mon serveur ?

Exécutez `systemctl list-units –type=service | grep fpm`. Sur les systèmes Debian/Ubuntu avec plusieurs versions du PPA `ondrej/php`, vous verrez des entrées comme `php7.4-fpm.service` et `php8.2-fpm.service`. Sur RHEL/CentOS avec le dépôt Remi, la convention de nommage est `php74-php-fpm.service`.

Le redémarrage de PHP-FPM affecte-t-il les connexions de base de données actives ou les sessions utilisateur ?

Un redémarrage brutal (`systemctl restart`) termine immédiatement tous les processus workers, ce qui ferme toutes les connexions de base de données persistantes détenues par ces workers. Les sessions utilisateur stockées dans des fichiers ou une base de données ne sont pas affectées car elles persistent indépendamment des workers PHP-FPM. Un rechargement progressif (`systemctl reload`) permet aux workers de terminer leurs requêtes en cours, de sorte que les connexions persistantes sont fermées proprement.

Pourquoi PHP-FPM échoue-t-il à démarrer après un redémarrage ?

Les causes les plus courantes sont une erreur de syntaxe dans `php.ini` ou un fichier de configuration de pool, un conflit de port ou de chemin de socket (un autre processus écoute déjà sur l’adresse `listen` configurée), ou des permissions insuffisantes sur le répertoire du socket. Exécutez `php-fpm<ver> -t` pour valider la syntaxe de la configuration, et vérifiez `journalctl -u php<ver>-fpm` pour le message d’erreur exact.

Puis-je redémarrer PHP-FPM sans privilèges root ou sudo ?

Pas sur une installation Linux standard. Le processus maître de PHP-FPM s’exécute en tant que root (il abandonne les privilèges au profit du `user`/`group` configuré pour les processus workers), et la gestion des services système nécessite des privilèges élevés. Sur les environnements d’hébergement partagé, le fournisseur d’hébergement gère les redémarrages de PHP-FPM via son panneau de contrôle. Pour un contrôle total sur PHP-FPM, un plan VPS Hosting avec accès root est la solution appropriée.