2016-11-29 5 views
0

Il existe une méthode couramment utilisée pour démarrer un processus d'arrière-plan en PHP à l'aide de la fonctionnalité exec ou shell_exec.Exécution d'un script en arrière-plan à partir de php exec/shell_exec L'appel échoue et réapparaît à l'endroit où il fonctionnait auparavant

J'ai eu du succès avec cela par le passé avec l'envoi par email par lots, et l'envoi de données aux API en arrière-plan.

Dans une page PHP que vous appelleriez par ajax, vous faites quelque chose comme ceci:

echo 'process running'; 
shell_exec('/usr/bin/php -q path_to_background_script.php > /dev/null &'); 
exit; 

Le processus d'arrière-plan fonctionne normalement comme si elle est appelée par le propriétaire de l'utilisateur php comme un processus terminal. Récemment cependant, sous un système FASTCGI (ea-php56), j'ai trouvé que cette méthode a cessé de fonctionner. Au lieu d'un processus commençant par une requête Web vers la page d'appel, le script d'arrière-plan se termine de manière continue et est ré-généré avec un nouvel ID de processus. Il est intéressant de noter que la seule façon d'arrêter cette réapparition continue est de désactiver la ligne dans le script appelant qui démarre le processus. La régénération s'arrête immédiatement lorsque vous enregistrez le fichier appelant sans l'appel au script d'arrière-plan. Cela me dit que c'est en fait le script appelant (demandé par le navigateur) qui est en train d'être ré-engendré.

Voici à quoi ressemble le re-spawning depuis le terminal racine. Notez que le PID change chaque fois que je regarde:

[[email protected]*** public_html]# ps -ef | grep php 
*user* 725  1 7 23:53 ?  00:00:00 /opt/cpanel/ea-php56/root/usr/bin/php-cgi /home/*user*/public_html/background-script_exec.php 
root  727 32411 0 23:53 pts/1 00:00:00 grep php 
[[email protected] public_html]# ps -ef | grep php 
*user* 757  1 5 23:53 ?  00:00:00 /opt/cpanel/ea-php56/root/usr/bin/php-cgi /home/*user*/public_html/background-script_exec.php 
root  759 32411 0 23:53 pts/1 00:00:00 grep php 
[[email protected] public_html]# ps -ef | grep php 
*user* 781  1 12 23:54 ?  00:00:00 /opt/cpanel/ea-php56/root/usr/bin/php-cgi /home/*user*/public_html/background-script_exec.php 

J'ai essayé de désactiver "service PHP-FPM pour cPanel Daemons". J'ai essayé 'ignore_user_abort()'. La fonction fastcgi_finish_request() n'est pas disponible, donc impossible de l'essayer. J'ai essayé de créer un script shell à la place pour appeler le script PHP d'arrière-plan, que j'appelle du script appelant - mais cela fait exactement la même chose.

En plus de désactiver la possibilité de déclencher des scripts d'arrière-plan à partir d'une page Web PHP, ce nouveau comportement PHP FastCGI crée un processus de re-spawning erratique qui ne s'arrête pas sans intervention mentionnée ci-dessus. Il a rendu les fonctions shell_exec/exec instables!

problème semble similaire à celui rapporté ici: php exec/shell_exec/system/popen/proc_open runs calling script itself infinite number of times on linux

mais la suggestion présentée ici ne permet pas dans ce cas.

Répondre

0

Cela semble résoudre le problème. Utilisation de la « php5-cli » au lieu de « php »

shell_exec('/usr/bin/php5-cli path_to_background_script.php > /dev/null &'); 

j'avais essayé au début « php-cli » et trouvé qu'il n'existait pas - je ne pensais pas à vérifier qu'il a été nommé différemment!

Si des problèmes similaires, un coup d'oeil pour les binaires php:

>>ls /usr/bin/php* 
>>/usr/bin/php /usr/bin/php5 /usr/bin/php5-cli /usr/bin/php-config /usr/bin/phpize 

utiliser celui qui est pour la ligne de commande, et il devrait alors fonctionner correctement. Notez que ce problème concernait spécifiquement un système fastcgi-php easy-apache de Linux fonctionnant sous Centos.