Aller au contenu

cPanel et WHMPHP Mis à jour le 2026-11-01

Corriger « apache_php_fpm appears to be down » dans cPanel

Quand WHM vous écrit que le service apache_php_fpm appears to be down, vous pouvez trouver quelle version PHP-FPM ea-php est tombée, lire la ligne de journal qui nomme la cause et la corriger. Vous confirmerez ensuite que le service, la surveillance et vos sites WordPress sont de nouveau en santé.

Votre serveur cPanel & WHM vous a écrit que le service apache_php_fpm « appears to be down », et vous devez savoir quelle version de PHP a flanché et pourquoi. Les sites qui exécutent PHP par PHP-FPM renvoient peut-être déjà des erreurs, souvent une page 503 « Service Unavailable ». L’alerte ne peut pas nommer la version, parce qu’apache_php_fpm est un seul nom pour tous les services PHP-FPM du serveur. Trouvez le service ea-phpXY-php-fpm qui est tombé, puis lisez son propre journal, qui nomme habituellement la cause en une ligne. Corrigez cette cause dans le fichier que cPanel conserve, redémarrez une seule fois et confirmez que la surveillance et les sites sont d’accord.

Ce que vous allez accomplir

  • Savoir quelle version de PHP installée s’est arrêtée, même si l’alerte ne nomme que apache_php_fpm.
  • Lire le journal du service et le test de configuration qui expliquent l’arrêt.
  • Corriger les six causes qui reviennent sans cesse, chacune à l’endroit qui survit à la prochaine reconstruction de cPanel.
  • Confirmer que le service tourne, que la surveillance se tait et qu’un site WordPress répond 200.

Prérequis

  • Un accès root au serveur, par SSH ou par WHM » Server Configuration » Terminal.
  • cPanel & WHM avec EasyApache 4, le système de cPanel qui installe Apache et PHP sous forme de paquets, sur AlmaLinux, Rocky Linux ou CloudLinux. Les chemins ci-dessous viennent de ces systèmes. Sur cPanel pour Ubuntu, certains chemins peuvent différer; fiez-vous à ceux qu’affichent les étapes 2 et 3.
  • Au moins un domaine réglé sur PHP-FPM dans WHM » Software » MultiPHP Manager (Gestionnaire MultiPHP). Si aucun domaine n’utilise PHP-FPM, l’alerte porte sur un service dont vous n’avez pas besoin; la dernière section traite de ce cas.
  • Les exemples utilisent ea-php83 comme version en panne et boutique-lac.ca comme domaine. Remplacez-les par les vôtres.

Si vous ne savez pas quel fichier appartient à quelle version, la carte des fichiers, du php.ini et de FPM d’ea-php donne chaque chemin utilisé ici.

Comment ça fonctionne

PHP-FPM, le FastCGI Process Manager, garde un groupe de processus PHP prêts à recevoir les requêtes d’Apache. FastCGI est le protocole qu’Apache utilise pour passer une requête à un programme distinct. Sur cPanel, chaque version de PHP a son propre service PHP-FPM avec un processus maître, comme ea-php82-php-fpm et ea-php83-php-fpm. Chaque maître fait tourner un pool par domaine sur cette version, et chaque pool écoute sur un fichier socket, un fichier spécial qu’Apache ouvre pour parler au pool.

cPanel regroupe tous ces maîtres sous un seul nom de service, apache_php_fpm, avec un seul script de redémarrage, /usr/local/cpanel/scripts/restartsrv_apache_php_fpm. Le moniteur de services s’appelle chkservd. Il tourne dans tailwatchd, le démon de cPanel qui surveille les journaux, et, par défaut, vérifie chaque service aux cinq minutes. Quand la vérification d’apache_php_fpm échoue, chkservd essaie le script de redémarrage et vous écrit. Une seule version en panne suffit à faire échouer toute la vérification. C’est pourquoi le courriel ne peut pas vous dire quelle version regarder.

chkservd vérifie apache_php_fpm aux cinq minutes et envoie une alerte qui ne nomme aucune version; apache_php_fpm regroupe les maîtres PHP-FPM ea-php82, ea-php83 et ea-php84, deux sont en marche avec leurs pools et sockets qui répondent 200, et ea-php83 est celui en échec dont les sites renvoient 503, avec systemctl status, journalctl et le journal d'erreurs de FPM comme premiers endroits à lire

Les autres maîtres continuent de servir leurs sites pendant qu’un seul est tombé. Seuls les domaines de la version en panne cessent de fonctionner. Repérer rapidement quels sites marchent encore vous donne donc déjà un indice.

Étapes

  1. Demandez à cPanel l’état actuel. Le problème s’est peut-être réglé, parce que chkservd a tenté un redémarrage avant de vous écrire :

    /usr/local/cpanel/scripts/restartsrv_apache_php_fpm --check

    Résultat attendu : un message qui indique qu’apache_php_fpm est en marche (running). Un message qui le dit arrêté ou en échec veut dire que le problème est toujours là.

    Une réponse saine ne termine pas le travail. Un service instable, qui tombe et revient, a l’air sain entre deux vérifications. Passez à l’étape 2 même si la vérification réussit.

  2. Trouvez quelle version est tombée. Listez chaque service PHP-FPM ea-php avec son état :

    systemctl list-units 'ea-php*-php-fpm.service' --all --no-pager

    Exemple de sortie :

      UNIT                     LOAD   ACTIVE SUB     DESCRIPTION
  ea-php82-php-fpm.service loaded active running The PHP FastCGI Process Manager
● ea-php83-php-fpm.service loaded failed failed  The PHP FastCGI Process Manager
  ea-php84-php-fpm.service loaded active running The PHP FastCGI Process Manager

    La ligne marquée failed est votre version. Si chaque ligne indique active running, la panne est passée; cherchez alors à quelle heure elle s’est produite à l’étape 4.

  3. Lisez pourquoi ce maître s’est arrêté. Commencez par systemd, puis par le journal PHP-FPM propre à la version :

    systemctl status ea-php83-php-fpm --no-pager
journalctl -u ea-php83-php-fpm -n 50 --no-pager
tail -n 40 /opt/cpanel/ea-php83/root/usr/var/log/php-fpm/error.log

    Exemple de sortie (abrégé) :

    × ea-php83-php-fpm.service - The PHP FastCGI Process Manager
     Active: failed (Result: exit-code) since Sun 2026-11-01 03:41:17 EDT; 9min ago
[01-Nov-2026 03:41:17] ERROR: [/opt/cpanel/ea-php83/root/etc/php-fpm.d/boutique-lac.ca.conf:21] unknown entry 'pm.max_childs'
[01-Nov-2026 03:41:17] ERROR: failed to load configuration file '/opt/cpanel/ea-php83/root/etc/php-fpm.conf'
[01-Nov-2026 03:41:17] ERROR: FPM initialization failed

    La première ligne ERROR est la cause, et les autres en découlent. Le nom du fichier de pool vous dit quel domaine corriger. Si Active: indique que le processus a été tué, ou affiche code=dumped (un plantage), le maître est mort au lieu de refuser un réglage. Passez aux causes B et D de l’étape 6.

  4. Voyez ce que chkservd a vu, et quand. Le moniteur écrit le résultat de chaque vérification dans son propre journal :

    grep -n 'apache_php_fpm' /var/log/chkservd.log | tail -n 20

    Résultat attendu : des lignes qui mentionnent apache_php_fpm autour de l’heure de l’alerte. Comparez ces heures avec l’heure since de l’étape 3. Si les alertes se répètent aux cinq minutes, le redémarrage échoue chaque fois et la cause est toujours là. Le courriel d’alerte peut aussi citer un numéro d’erreur du script de redémarrage. Ce numéro ne nomme pas la cause; prenez plutôt la raison dans les journaux de l’étape 3.

  5. Testez la configuration sans toucher au service en marche. PHP-FPM peut vérifier son fichier principal et chaque fichier de pool qu’il inclut :

    /opt/cpanel/ea-php83/root/usr/sbin/php-fpm -t -y /opt/cpanel/ea-php83/root/etc/php-fpm.conf

    Exemple de sortie, après la correction :

    [01-Nov-2026 03:58:02] NOTICE: configuration file /opt/cpanel/ea-php83/root/etc/php-fpm.conf test is successful

    Lancez ce test après chaque correction de l’étape 6. Ne redémarrez que lorsqu’il affiche test is successful.

  6. Corrigez la cause nommée par le journal. Associez la première ligne d’erreur à l’un de ces cas.

    A. Un réglage de pool invalide, comme unknown entry ou invalid value. Il suit souvent une modification à la main des réglages PHP-FPM d’un domaine. cPanel construit chaque fichier de pool à partir du fichier YAML du domaine (un fichier de réglages en texte brut); corrigez donc le YAML, ici /var/cpanel/userdata/lacnord/boutique-lac.ca.php-fpm.yaml. Rectifiez la clé ou la valeur, puis demandez à cPanel de vérifier et de reconstruire ce domaine :

    /usr/local/cpanel/scripts/php_fpm_config --check
/usr/local/cpanel/scripts/php_fpm_config --rebuild --domain=boutique-lac.ca; echo "exit=$?"

    Résultat attendu : --check liste les configurations sans erreur pour le domaine, et la reconstruction affiche exit=0. Si quelqu’un a modifié /opt/cpanel/ea-php83/root/etc/php-fpm.d/boutique-lac.ca.conf à la main, la reconstruction le remplace, et c’est voulu. Un fichier de pool que cPanel ne gère pas peut aussi bloquer le démarrage. Un www.conf égaré, ou un .conf copié et oublié dans php-fpm.d, est le cas habituel, et --check le signale comme orphelin. Déplacez-le dans /root.

    B. Une extension qui ne se charge pas après un changement de version ou une mise à jour. Interrogez le PHP en ligne de commande de la même version, qui lit le même dossier php.d :

    /opt/cpanel/ea-php83/root/usr/bin/php -m > /dev/null

    Exemple de sortie (abrégé) :

    PHP Warning:  PHP Startup: Unable to load dynamic library 'redis.so' (tried: /opt/cpanel/ea-php83/root/usr/lib64/php/modules/redis.so (/opt/cpanel/ea-php83/root/usr/lib64/php/modules/redis.so: cannot open shared object file: No such file or directory), ...) in Unknown on line 0

    Si la commande n’affiche rien, toutes les extensions se sont chargées. Un avertissement comme celui-ci n’arrête pas toujours PHP-FPM, mais une extension qui plante au chargement, oui. Déplacez le .ini correspondant hors de /opt/cpanel/ea-php83/root/etc/php.d/ vers /root. Réinstallez ensuite cette extension pour cette version à partir de sa source, soit WHM » Software » EasyApache 4, soit WHM » Software » Module Installers.

    C. OPcache a demandé plus de mémoire que le serveur peut en donner. La ligne du journal contient Unable to allocate shared memory segment. Remettez l’ancienne valeur d’opcache.memory_consumption. Dimensionner les réglages OpCache sur cPanel explique comment choisir une valeur à partir des compteurs du cache.

    D. Le tueur OOM du noyau a arrêté PHP-FPM. OOM veut dire « out of memory », manque de mémoire. Quand la mémoire vive s’épuise, le noyau tue un processus pour en libérer. Cherchez dans le journal du noyau :

    journalctl -k --since '2 hours ago' --no-pager | grep -i 'out of memory'

    Exemple de sortie :

    Nov 01 03:41:09 cp1 kernel: Out of memory: Killed process 30418 (php-fpm) total-vm:1873412kB, anon-rss:1290844kB, file-rss:0kB, shmem-rss:6120kB, UID:1004 pgtables:2920kB oom_score_adj:0

    Un UID autre que 0 est un processus de travail, qui tourne sous l’utilisateur du compte. UID:0 est un maître, qui tourne en root, et c’est ce cas qui arrête toute une version. Dans les deux cas, le redémarrage fonctionnera, mais le serveur manquera encore de mémoire. Baissez pm_max_children, le plafond de processus par pool, dans les fichiers YAML des domaines les plus achalandés. Reconstruisez, puis lisez la dernière section de cet article.

    E. Un disque plein, ou plus d’inodes libres. Les inodes sont les cases de fichiers qu’un système de fichiers distribue, et un disque peut en manquer avant de manquer d’espace. Le journal affiche No space left on device, souvent quand le maître tente de créer un socket ou son fichier PID, qui enregistre le numéro de son processus. Vérifiez les deux :

    df -h / /opt /var /tmp
df -i / /opt /var /tmp

    Résultat attendu : chaque ligne sous 90 % dans les colonnes Use% et IUse%. Une ligne à 100 % est votre cause. Libérez de l’espace à cet endroit, souvent de vieilles sauvegardes, des journaux ou des fichiers de session, puis redémarrez.

    F. Une version de PHP retirée alors que des domaines l’utilisent encore. Comparez ce qui est installé avec ce que les domaines demandent :

    whmapi1 php_get_installed_versions
whmapi1 php_get_vhost_versions | grep -E '^ +(version|vhost): '

    Chaque version: de la deuxième liste doit figurer dans la première. Un domaine sur une version disparue n’a plus de PHP fonctionnel, et systemctl status ea-php81-php-fpm répond Unit ea-php81-php-fpm.service could not be found. Déplacez ces domaines vers une version installée dans le Gestionnaire MultiPHP, puis lancez /usr/local/cpanel/scripts/php_fpm_config --rebuild pour tout le serveur.

  7. Redémarrez par cPanel, une seule fois. Le script de redémarrage démarre chaque version et garde chkservd synchronisé :

    /usr/local/cpanel/scripts/restartsrv_apache_php_fpm

    Résultat attendu : le script attend le service, puis indique qu’apache_php_fpm est en marche. S’il signale un échec, retournez à l’étape 3. Le journal montrera une nouvelle première erreur.

Valider que ça fonctionne

  1. Chaque maître tourne. Relancez la commande de l’étape 2. Chaque ligne doit indiquer active running.

  2. La configuration passe toujours le test. Lancez le test de l’étape 5 pour la version corrigée. Il doit afficher test is successful.

  3. La surveillance est d’accord. Attendez la prochaine vérification, cinq minutes au plus par défaut. La commande de l’étape 4 ne doit montrer aucun nouvel échec après votre redémarrage, et chkservd peut aussi envoyer un avis de rétablissement par courriel. WHM » Server Status » Service Status doit montrer le service PHP-FPM comme actif.

  4. Un site sur la version corrigée répond. Choisissez un domaine WordPress qui utilise la version réparée :

    curl -s -o /dev/null -w '%{http_code}\n' https://boutique-lac.ca/
curl -s -o /dev/null -w '%{http_code}\n' https://boutique-lac.ca/wp-login.php

    Résultat attendu : 200 pour les deux. Un 503 veut dire qu’Apache n’arrive toujours pas à joindre le pool; le premier point du dépannage couvre ce cas.

  5. Les domaines pointent vers des versions installées. Lancez les deux commandes whmapi1 de la cause F. Chaque version: doit figurer dans la liste des versions installées.

Dépannage

  • Le service tourne, mais les sites d’une version affichent 503. Apache n’arrive pas à joindre le socket de ce domaine. Cherchez dans /etc/apache2/logs/error_log des lignes AH02454, le code d’Apache pour une connexion ratée à un socket FastCGI, qui nomment un socket sous /opt/cpanel/ea-php83/root/usr/var/run/php-fpm/. Lancez /usr/local/cpanel/scripts/php_fpm_config --rebuild --domain=boutique-lac.ca, puis redémarrez avec le script de l’étape 7.
  • L’alerte arrive aux cinq minutes. Chaque vérification lance le redémarrage, et chaque redémarrage bute sur la même erreur. Arrêtez de redémarrer à la main. Lancez le test de l’étape 5, qui montre l’erreur sur laquelle le redémarrage bute.
  • L’alerte est arrivée une seule fois, pendant un redémarrage du serveur. La vérification peut tomber pendant que les services s’arrêtent ou démarrent. Si l’étape 2 montre que tout tourne et que le journal de l’étape 4 est propre ensuite, vous pouvez vous arrêter là.
  • La reconstruction affiche un code de sortie autre que 0. Le fichier YAML contient fort probablement une erreur de syntaxe. Il manque souvent une espace après un deux-points, ou une tabulation sert à l’indentation. Corrigez le fichier, puis lancez /usr/local/cpanel/scripts/php_fpm_config --check avant de reconstruire de nouveau.
  • Le même domaine retombe en panne après quelques jours. Quelqu’un modifie encore le fichier de pool généré, ou l’installateur d’une extension y ajoute un réglage à la main. Mettez le réglage dans le fichier YAML du domaine ou dans le Gestionnaire MultiPHP, pour que la reconstruction le conserve.

Quand ce n’est pas la bonne approche

Si le tueur OOM revient plus d’une fois à la cause D, vous avez un problème de capacité, pas un problème de PHP-FPM. Chaque redémarrage vous achète quelques heures. Une correction durable demande moins de processus par pool, moins de versions de PHP actives ou plus de mémoire. La page du script php_fpm_config de cPanel recommande au moins 2 Go de mémoire vive disponible, ou au moins 30 Mo par domaine, avant d’activer PHP-FPM.

Sur les serveurs CloudLinux où les sites passent par mod_lsapi, un module Apache qui exécute PHP sans PHP-FPM, ou sur LiteSpeed Web Server, ces sites n’utilisent pas apache_php_fpm. Une alerte peut alors concerner des domaines restés sur PHP-FPM, ou un service que personne n’utilise. Vérifiez la liste de l’étape 2 et le Gestionnaire MultiPHP avant de changer quoi que ce soit. Ne désactivez la surveillance dans WHM » Service Configuration » Service Manager qu’après avoir confirmé qu’aucun domaine n’utilise PHP-FPM. Si vous louez un seul compte sur le serveur de quelqu’un d’autre, ces commandes ne sont pas à votre portée. Envoyez à votre hébergeur l’heure de l’alerte et les domaines touchés. Pour le comportement des redémarrages des autres services cPanel, voyez redémarrer les services cPanel sans risque. La documentation TailWatch de cPanel décrit comment chkservd vérifie et redémarre les services.

Si les alertes sonnent dans une pièce vide après les heures, c’est exactement ce que ferme la Surveillance et intervention 24/7 — planifiez une revue de surveillance.