Edit report at https://bugs.php.net/bug.php?id=70185&edit=1
ID: 70185
Comment by: php at grindau dot com
Reported by: kobenews at cox dot net
Summary: php-fpm restarts master process in a loop when
exec() and using ssh multiplexing
Status: Open
Type: Bug
Package: FPM related
Operating System: CentOS release 6.6 (Final)
PHP Version: 5.4.43
Block user comment: N
Private report: N
New Comment:
I am having the same issue! It took me ages to find out whats the reason.
I am running the latest php-7.1.2 under archx64.
Executing this command:
shell_exec('/usr/lib/node_modules/csso/bin/csso
'.ROOT_PATH.'/tmp/style-critical-unoptimized.css --output
'.ROOT_PATH.'/tmp/style-critical.css');
which should just easily grap a normal css file and compress it down causes the master process to
restart itself hundred times a second or even more causing 100% cpu load on the server.
Previous Comments:
------------------------------------------------------------------------
[2017-02-24 13:52:08] sylvain at com-ocean dot com
Same bug by executing a bash script calling rsync command.
with PHP 5.6.30 and Debian 7.10
------------------------------------------------------------------------
[2016-01-22 08:06:02] i dot priladnyh at gmail dot com
Ubuntu 14.04
php5-fpm 5.5.9
Same problem with launch ssh session using ControlMaster. FPM load CPU to 100%.
Problem with FPM solved by launch SSH session with flag -f (background). But then SSH connection
multiplexing don`t correctly works.
------------------------------------------------------------------------
[2015-09-09 02:18:52] kobenews at cox dot net
php at plainview dot se: glad I'm not the only one experiencing this bug. Now the trick, is to
get a fix.
I am running:
PHP 5.4.43 on CentOS 6.7
------------------------------------------------------------------------
[2015-09-08 20:39:28] php at plainview dot se
Finally, someone else with the same bug! I have been dealing with it for years and, until I read
this, used a separate php-fastcgi to deal with the constant child spamming.
My previous setup was a Debian 7 with 5.4.4-14+deb7u14.
My current setup is a Debian 8 with 5.6.9+dfsg-0+deb8u1.
Both exhibit the exact same behaviour: when a multiplexed SSH is exec()ed it goes spawn crazy, with
children dying left and right:
[08-Sep-2015 21:32:36] NOTICE: [pool www] child 30721 exited with code 0 after 0.011428 seconds from
start
[08-Sep-2015 21:32:36] NOTICE: [pool www] child 30722 exited with code 0 after 0.011916 seconds from
start
[08-Sep-2015 21:32:36] NOTICE: [pool www] child 30723 exited with code 0 after 0.011527 seconds from
start
[08-Sep-2015 21:32:36] NOTICE: [pool www] child 30724 exited with code 0 after 0.012399 seconds from
start
[08-Sep-2015 21:32:36] NOTICE: [pool www] child 30725 exited with code 0 after 0.011333 seconds from
start
[08-Sep-2015 21:32:36] NOTICE: [pool www] child 30726 exited with code 0 after 0.010918 seconds from
start
[08-Sep-2015 21:32:36] NOTICE: [pool www] child 30727 exited with code 0 after 0.010977 seconds from
start
[08-Sep-2015 21:32:36] NOTICE: [pool www] child 30728 exited with code 0 after 0.011124 seconds from
start
The result is 100% CPU load and a sluggish system.
The source of the problem is, as kobenews says, multiplexing SSH. I do it via a series of bash
scripts that are execed by PHP.
Original script:
#!/bin/bash
CONTROLPATH=/var/www/mail_scripts/master-mail_scripts
MAIL_SCRIPTS_COMMAND="ssh -o StrictHostKeyChecking=no -l mail_scripts -o
ControlPath=$CONTROLPATH -i /var/www/mail_scripts/mail_scripts TARGET.COM"
# If the socket doesn't exist, create it.
if [ ! -e $CONTROLPATH* ] ; then
$MAIL_SCRIPTS_COMMAND -fNM
fi
# Execute the requested command.
$MAIL_SCRIPTS_COMMAND /home/mail_scripts/the_command $@
What I did was I moveed -f in front of TARGET.COM and started the master manually, outside of PHP.
After that PHP seems fine with running the script without spawnflooding.
------------------------------------------------------------------------
[2015-08-07 20:13:58] kobenews at cox dot net
Updated summary.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=70185
--
Edit this bug report at https://bugs.php.net/bug.php?id=70185&edit=1