Résolution de l'erreur « Aucun fichier ou répertoire de ce type » causée par des incohérences entre la configuration de surveillance Monit et PHP-FPM.

Un bain de sang déclenché par un chemin de socket

L'histoire se déroule comme suit.

J'ai un ami dont le serveur a de nouveau planté le mois dernier.

Il est venu me voir et m'a expliqué que Monit signalait sans cesse des erreurs, indiquant qu'il ne trouvait pas le fichier socket php-fpm. Le service a alors commencé à redémarrer fréquemment et la charge a explosé. À trois heures du matin, il a reçu un appel d'urgence pour réparer le serveur.

Je t'avais dit de ne pas paniquer et de me montrer les journaux de surveillance.

Quand je l'ai regardé, waouh, il était truffé de ce genre d'erreurs :

erreur : erreur de connexion au socket Unix /run/php/php8.4-fpm.sock — Aucun fichier ou répertoire de ce type erreur : 'php8.4-fpm' faiTest du protocole LED [DEFAULT] sur /run/php/php8.4-fpm.sock — Impossible de créer un socket Unix pour /run/php/php8.4-fpm.sock

Je lui ai demandé : « Où est ton fichier socket maintenant ? »

Il a dit qu'il ne savait pas, alors je l'ai installé avec les paramètres par défaut.

Je t'ai dit d'attendre, je vais vérifier pour toi.

Je me suis ensuite connecté en SSH et j'ai vu que son fichier socket s'appelait... /run/php/php8.4-fpm-etufo.org.sock.

J'ai dit : « Mon pote, ton chemin de socket est composé de deux choses différentes, ce serait un miracle s'il pouvait communiquer. »

Aujourd'hui, je vais analyser cela en détail et vous l'expliquer, et je vais également vous proposer une solution au problème.

Vous pensez que la surveillance vous protège, mais en réalité elle vous nuit.

Commençons par parler du type d'erreur le plus courant dans les journaux de surveillance.

Lorsque vous voyez ceci :

Erreur : erreur de connexion au socket Unix /run/php/php8.4-fpm.sock — Aucun fichier ou répertoire de ce type

Cela indique que monit tente de détecter le service php-fpm via ce socket, mais qu'il ne parvient pas à trouver le fichier.

Ensuite, monit tentera de redémarrer le service et les journaux afficheront :

info : 'php8.4-fpm' tente de redémarrer info : 'php8.4-fpm' stop : '/usr/sbin/service php8.4-fpm stop' info : 'php8.4-fpm' start : '/usr/sbin/service php8.4-fpm start'

Ça a l'air plutôt intelligent, non ? Ça se répare automatiquement.

Mais le problème, c'est que ces redémarrages fréquents constituent le véritable désastre.

Imaginez ceci : lors du redémarrage de php-fpm, toutes les requêtes en cours sont interrompues, toutes les sessions peuvent être perdues et toutes les connexions doivent être rétablies. Si le service redémarre et échoue à plusieurs reprises en peu de temps, la charge du serveur explosera instantanément.

Les journaux révéleront également davantage d'informations, comme celles-ci :

erreur : 'etUfoLa charge moyenne de .org (15 min) de 8.8 correspond à la limite de ressources [charge moyenne (15 min) > 8.0] erreur : 'etUfoL'utilisation du processeur par le système .org (33.9 %) correspond à la limite de ressources [utilisation du processeur > 30.0 %].

Le serveur était déjà fortement sollicité, mais le système de surveillance continuait de le redémarrer sans cesse. Au lieu d'éteindre l'incendie, cela ne faisait que l'aggraver.

L'essence du problème : la clé et la serrure ne correspondent pas.

À y regarder de plus près, le problème est en réalité assez simple.

Le chemin du socket spécifié dans le fichier de configuration monit est :/run/php/php8.4-fpm.sock

Cependant, le chemin d'accès réel au socket sur lequel php-fpm s'exécute est :/run/php/php8.4-fpm-etufo.org.sock

Si une fonction est censée détecter le fichier A, mais que l'autre est en réalité le fichier B, la détection échouera évidemment.

C'est comme quelque chose.

Vous avez une clé, enfermée dans une autre pièce.

Vous utilisez votre clé pour ouvrir la porte tous les jours, mais à chaque fois vous constatez qu'elle ne s'ouvre pas, et vous en concluez que la serrure est cassée.

En fait, la serrure n'est pas cassée ; c'est juste que votre clé ne correspond pas à la serrure.

résoudreSurveillance du moniteurConfiguration incompatible avec PHP-FPM

Option 1 : Modifier la configuration de Monit.

Si vous souhaitez conserver la configuration socket existante de php-fpm, modifiez alors la configuration de monit.

Localisez le fichier de configuration de monit et modifiez les éléments suivants :

if failed unixsocket /run/php/php8.4-fpm.sock then restart

Changez-le en :

if failed unixsocket /run/php/php8.4-fpm-chenweiliang.com.sock then restart

Procédez ensuite à un rechargement :

sudo monit reload

C'est ça.

Option 2 : Modifier la configuration de php-fpm.

Si vous souhaitez utiliser le chemin par défaut, modifiez la configuration du pool de php-fpm.

编辑 /etc/php/8.4/fpm/pool.d/chenweiliang.com.confModifiez la commande d'écoute comme suit :

listen = /run/php/php8.4-fpm.sock

Redémarrez ensuite php-fpm :

sudo systemctl restart php8.4-fpm

C'est ça.

Les deux solutions permettent de résoudre le problème ; votre choix dépendra de votre situation particulière.

Combien de sites sont hébergés sur votre serveur ? Chaque site possède-t-il un socket indépendant ? S'il n'y a qu'un seul site, le chemin par défaut sera plus simple.

Permettez-moi de parler avec le cœur.

Je crois sincèrement que ces types de problèmes de configuration sont les plus facilement négligés, mais aussi les plus impactants sur la stabilité du serveur lors de la maintenance.

Si un chemin de socket est mal configuré, tout peut sembler calme en apparence, mais en réalité, le système de surveillance continue de donner de fausses alertes, le service redémarre sans cesse de manière aléatoire et la charge augmente inexplicablement.

Vous pourriez penser que le serveur est trop ancien et a besoin d'une mise à niveau, mais il se pourrait en réalité que le chemin d'accès dans le fichier de configuration soit incorrect.

Comme l'a dit un jour un de mes collègues les plus expérimentés : « La précision de la surveillance est la première ligne de défense pour garantir la stabilité du service. »

Le succès ou l'échec repose sur les détails, et cela est absolument vrai dans un environnement serveur.

À compter d'aujourd'hui, vérifiez votre configuration de surveillance. Ne laissez pas ce problème, en apparence anodin, mettre votre serveur hors service.

Merci d'avoir lu mon article. À bientôt !