Comment déboguer une erreur de segfault dans le noyau php5-fpm?
Il y a quelques semaines, mon démon OSSEC a commencé à m'envoyer des syslogs concernant un segfault dans mon php5-fpm. Voici la partie des journaux:
Dec 19 15:09:38 mydropplet kernel: [165740.998932] php5-fpm[26936]: segfault at 7fff621ad001 ip 000000000079fe74 sp 00007fff621a5040 error 6 in php5-fpm[400000+800000]
Alors j’ai jeté un œil dans mes journaux d’erreurs pour voir si j’avais eu quelques PHP erreurs quelque part qui étaient à l’origine du segfault (étant donné que je ne suis pas sûr de ce que cela signifie, mais cela ressemble à quelque chose dans le PHP core) Mes journaux d’erreur contenaient ceci (informations d’identification supprimées):
2015/12/19 01:36:49 [error] 6177#0: recv() failed (111: Connection refused) while resolving, resolver: xxx.xxx.xxx.xxx:xx
2015/12/19 01:36:54 [error] 6177#0: gv.symcd.com could not be resolved (110: Operation timed out) while requesting certificate status, responder: gv.symcd.com
2015/12/19 02:00:06 [error] 6178#0: recv() failed (111: Connection refused) while resolving, resolver: xxx.xxx.xxx.xxx:xx
2015/12/19 02:00:11 [error] 6178#0: recv() failed (111: Connection refused) while resolving, resolver: xxx.xxx.xxx.xxx:xx
2015/12/19 02:00:16 [error] 6178#0: recv() failed (111: Connection refused) while resolving, resolver: xxx.xxx.xxx.xxx:xx
2015/12/19 02:00:21 [error] 6178#0: recv() failed (111: Connection refused) while resolving, resolver: xxx.xxx.xxx.xxx:xx
2015/12/19 02:00:26 [error] 6178#0: recv() failed (111: Connection refused) while resolving, resolver: xxx.xxx.xxx.xxx:xx
2015/12/19 02:00:31 [error] 6178#0: recv() failed (111: Connection refused) while resolving, resolver: xxx.xxx.xxx.xxx:xx
Alors j'ai regardé de plus près mes syslogs qui contenaient ça. Voici la même partie des journaux que je voyais dans les courriels d'OSSEC:
Dec 19 09:44:06 mydomain kernel: [146209.162601] php5-fpm[13787]: segfault at 7fff621ad001 ip 000000000079fe74 sp 00007fff621a5040 error 6 in php5-fpm[400000+800000]
Voici le reste de la journalisation:
Dec 19 09:44:59 mydomain postfix/anvil[26420]: statistics: max connection rate 1/60s for (smtp:195.22.126.137) at Dec 19 09:41:39
Dec 19 09:44:59 mydomain postfix/anvil[26420]: statistics: max connection count 1 for (smtp:195.22.126.137) at Dec 19 09:41:39
Dec 19 09:44:59 mydomain postfix/anvil[26420]: statistics: max cache size 1 at Dec 19 09:41:39
[...]
Dec 19 09:41:39 mydomain postfix/smtpd[26418]: connect from unknown[195.22.126.137]
Dec 19 09:41:39 mydomain postfix/smtpd[26418]: disconnect from unknown[195.22.126.137]
Je suis assez nouveau sur les serveurs autogérés, donc je ne sais pas comment déboguer celui-ci. Je gère mon site Web personnel sur ce serveur et la seule chose que j'ai faite il y a quelques semaines est d'installer un nouveau plug-in à partir du référentiel Wordpress, faute de temps pour rechercher une configuration appropriée, je l'ai rapidement activé et configuré. et il a bricolé le front-end de mon site. Alors je l'ai désactivé et j'ai décidé d'essayer plus tard. Après cela, les erreurs du noyau ont commencé à se produire.
J'ai donc complètement désinstallé le plugin en pensant que c'était peut-être la cause, mais cela n'a rien résolu. Le plugin n'aurait eu qu'un accès en écriture à mon répertoire Web et n'aurait pas été en mesure de modifier les paramètres de configuration principaux. Je ne suis pas sûr qu'il y ait un lien, mais je pensais le mentionner.
J'utilise également cette configuration PHP depuis octobre sans aucun problème. Je n'ai ajouté aucun module nouveau/étrange en PHP. C'est fondamentalement hors de la boîte, à part quelques précautions de sécurité. Avant de voir l'erreur, j'ai exécuté dist-upgrade dans le cadre de ma maintenance régulière:
Sudo apt-get dist-upgrade
Sudo apt-get update
Sudo shutdown -r now
C'était à peu près au même moment que l'installation du plugin. Pour tenter de corriger les erreurs, j'ai à nouveau exécuté les commandes, pensant que s'il y avait eu un bogue, un correctif aurait sûrement été installé. Ceci, cependant, n'a pas aidé. Donc, je ne sais plus quoi faire pour vaincre ça.
Mise à jour: Je suis revenu à un instantané précédent, et tout a fonctionné pendant environ une semaine, puis j'ai commencé à recevoir à nouveau des courriels concernant le même problème de faute grave peu après Noël. Je reviens donc à la case départ.
Tout conseil serait bon! Je suis en cours d'exécution serveur LEMP Ubuntu 14.04 LTS. Comment déboguer un problème comme celui-ci? Merci pour toute aide en avance.
Si vous pensez que l'erreur est liée à Nginx, vous devez publier vos journaux Nginx associés. Il y a des références à resolver dans vos journaux publiés, qui peuvent concerner Nginx.
Si le résolveur Nginx est en cause, vous pourrez peut-être résoudre le problème en utilisant des adresses IP brutes dans votre configuration Nginx au lieu de noms de domaine.
Vérifiez également votre version actuelle de php5-fpm par rapport à la dernière version disponible dans leur référentiel Git. Recherchez ensuite dans le journal des modifications du projet les modifications plus récentes que la version que vous utilisez. Si une version plus récente est disponible, reportez-vous à la section mise à niveau.
Les Segfaults impliquent un bug logiciel, pas un problème de configuration. Même en cas de mauvaise configuration, le logiciel ne devrait pas commettre d'erreur. Comme il semble que php5-fpm soit le processus à l'origine de l'erreur de segmentation, envisagez de signaler le bogue sur leur liste de diffusion ou sur le système de suivi des problèmes si ce n'est pas corrigé dans la dernière version.
Il est également possible que le logiciel fonctionnant via php5-fpm soit ce que segfault'ed et php5-fpm ne soit que le messager transmettant la notification d'un segfault. Encore une fois, le projet php5-fpm sera la référence incontournable pour déterminer comment les erreurs de segmentation se produisent avec ce logiciel.