depuis le 9 novembre, je trouve dans le fichier /logs/error_log de mon site de très nombreuses paires de lignes de ce type :
[proxy:error] [pid 18631:tid 140371786942208] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /var/www/php/[mon-domaine].sock (*) failed
[proxy_fcgi:error] [pid 18631:tid 140371786942208] [client 54.36.148.50:37788] AH01079: failed to make connection to backend: httpd-UDS
Je crois comprendre qu’il s’agit d’un échec de connexion d’Apache vers le module qui interprète le PHP. Pourtant mes pages fonctionnent bien et le PHP est interprété normalement (mais peut-être est-ce simplement que l’erreur ne se produit pas à chaque fois, et que je ne suis pas tombé dessus en consultant mes pages ?).
La même chose se retrouve sur deux sites distincts avec des configurations très différentes, donc je suppose que le problème vient du serveur et pas de paramètres qui dépendent de moi, mais je ne vois pas comment m’en assurer.
Avez-vous une explication et/ou un remède ?
À cette occasion, je me suis également aperçu que les logs ne « tournent » plus. Jusqu’au 9 octobre j’avais dans le répertoire /logs des fichiers error_log.1.gz à error_log.10.gz qui se décalaient tous les jours, et un fichier error_log avec les messages du jour. Depuis cette date, il n’y a plus qu’un fichier error_log qui cumule toutes les erreurs et s’allonge indéfiniment. Est-ce qu’un cron aurait oublié de repartir depuis le 10 octobre ?
On a signalé il y a déjà un moment que le fichier error_log n’était plus tourné, depuis parfois plusieurs mois sur certains espaces.
Pour le moment aucun fichier n’est énorme donc nous n’avons pas encore regardé ce point.
Cet accès au error_log (le access_log ne fonctionne pas depuis longtemps) va probablement sauter dans les mois qui viennent. C’est très gourmand d’aller écrire dans un fichier sur chaque espace web, et les erreurs peuvent être affichées avec ini_set('display_errors', 1); error_reporting(2047); en cas de problème.
Vous pouvez ignorer les erreurs {proxy*] du error_log, elles ne résultent pas d’un problème spécifique à vos sites.
Dans le passé, le error_log m’a permis de détecter des erreurs que je ne soupçonnais pas dans mes scripts PHP.
Changer display_errors, c’est bien pour déboguer quand on sait qu’il y a une erreur, mais parfois on ne s’en doute pas du tout. De plus, ça affiche les messages d’erreurs à tous les visiteurs, ce qui n’est pas toujours désirable, et ça ne marche pas pour les erreurs de syntaxe.
Bref, je regrette l’époque où les erreurs PHP apparaissaient dans le error_log. Comme ce n’est apparemment plus le cas, je suis d’accord qu’on peut supprimer le error_log sans gros inconvénient. Mais si on pouvait remettre un mécanisme quelconque qui permette de récupérer les erreurs PHP dans un fichier, ça serait bien pratique.
Le error_log peut aussi permettre de repérer qu’une page inexistante est demandée très souvent, ce qui signifie probablement qu’un lien vers cette page est présent quelque part, éventuellement sur un site hors d’Ouvaton, et d’agir en conséquence (faire corriger le lien, créer une redirection…).
Peut-être le meilleur compromis serait-il de rendre error_log’activable sur demande à partir d’Ouvadmin, comme pour les statistiques ?
On verra si on peut activer sur demande le error_log un de ces jours, merci pour l’idée !
Pour les pages inexistantes, les erreurs du client (4xx) sont orientées vers le access_log. Mais vous pouvez les trouver sur les stats de chaque site.
Et si besoin d’avoir les erreurs, sans les afficher aux clients et en gardant une trace dans un fichier de logs, vous pouvez ajouter des lignes comme ci-dessous dans le index.php de votre site :
Je ne me suis jamais penché sur ces paramètres parce que par défaut je trouvais tout ce que je voulais dans les logs, mais ce n’est pas bien compliqué.
