9 votes

Comment puis-je trouver et tuer une boucle PHP (processus) ?

J'ai un script php que j'ai développé et qui appelle une api externe dans une boucle. Il est en cours de test sur un VPS qui exécute LAMP sur Debian. J'ai remarqué ce matin que l'api ne répondait pas à mon script. Lorsque j'ai contacté le fournisseur, ils m'ont dit que mon serveur avait appelé l'api des milliers de fois par heure au cours des 10 dernières heures. Je suppose qu'un script php (sur lequel j'ai travaillé la veille et testé sur mon VPS) est entré dans une boucle infinie lors d'une des exécutions, et n'est jamais sorti (je l'ai testé à partir de l'invite de commande, et non via le web). J'ai essayé d'arrêter et de redémarrer Apache, mais le personnel de support de l'api dit que les appels continuent à venir de mon adresse de serveur. Comment puis-je trouver et arrêter le processus ? De plus, est-il possible que l'arrêt/redémarrage d'Apache ait résolu le problème, mais que l'api essaie toujours de trier les appels passés?

Veuillez me pardonner de ne pas avoir utilisé correctement mon environnement de test local.

Édition : Je ne connais pas le nom du processus, je dois découvrir le nom (ou le pid) en fonction du comportement.

18voto

fuujuhi Points 172

Depuis que vous exécutez manuellement le binaire php, que ce soit en utilisant php ou en utilisant le shebang php en haut du script, vous devrez trouver son PID et le tuer.

Vous pouvez utiliser pkill -9 php ou si pkill n'est pas présent, vous pouvez utiliser ps -efw | grep php | grep -v grep | awk '{print $2}' | xargs kill pour tuer tous les processus php.

De plus, si un processus établit des connexions réseau sortantes vers une API externe, ces connexions apparaîtront dans un netstat.

Vous devriez pouvoir faire un netstat -anop pour afficher toutes les connexions et le PID du processus qui les contrôle. Trouvez l'IP/nom d'hôte du serveur API externe, trouvez cet IP/nom d'hôte dans la liste du netstat, tuez le PID concerné.

4voto

user238125 Points 21

Si j'ai bien compris votre message, vous avez exécuté un script depuis PHP-CGI à travers votre console et il se peut que quelque chose ait mal tourné et ait spammé les serveurs API.

Il existe de nombreuses possibilités qui pourraient être à l'origine de ce problème. Tout d'abord, lorsque vous exécutez un script PHP en tapant simplement "php nomduscript.php", cela attend que le script PHP se termine pour revenir à votre session principale. Si vous fermez votre console pendant l'exécution du script, celui-ci s'arrêtera. Sauf si vous avez lancé votre PHP avec un "screen" ou un "&", il n'y a pas une seule possibilité pour que le script continue de s'exécuter.

Penchons-nous maintenant sur son fonctionnement. Si le script est entré dans une boucle infinie, ouvre un socket, cela signifie qu'il essaierait de se connecter au serveur API des centaines de fois par seconde. Cela signifie que le serveur cible devrait vous bannir dès les 10 premières secondes. Une chose que vous ne nous avez pas précisée est le débit des demandes de connexion vers le serveur cible. Le support des API vous a-t-il fourni plus d'informations à ce sujet ? Et si oui, que vous ont-ils dit ?

Cela dit, si votre VPS continue d'envoyer des requêtes aux serveurs, je vous suggère de faire

ps -A xa | grep php

et de vérifier les instances PHP en cours d'exécution. Vous avez peut-être accidentellement lancé un script PHP en arrière-plan en ajoutant un "&" à la fin de la ligne. Si cette commande renvoie quelque chose, trouvez l'identifiant du processus de l'application et terminez-le avec la commande suivante

kill -9 pid

Si cela ne fonctionne pas, redémarrez votre VPS et demandez-leur s'il continue d'envoyer des demandes de connexion (ce qui est actuellement impossible et cela voudrait dire que leur pare-feu a placé vos paquets en mode lent (ce qui signifie qu'il les a mis en file d'attente avec un délai pour leurs serveurs)).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X