Edit report at https://bugs.php.net/bug.php?id=77574&edit=1
ID: 77574
Updated by: bukka@php.net
Reported by: martin dot barker at thisisbeacon dot com
Summary: FPM failes to responed to apache2
Status: Re-Opened
Type: Bug
Package: FPM related
Operating System: Ubuntu 16.04.4 LTS
PHP Version: 7.2.14
Block user comment: N
Private report: N
New Comment:
I'm not sure what you mean by closing connection as FastCGI keeps the connection shared between
all workers in the pool so a single worker error should never close the connection between Apache2
and FPM. Could you elaborate a bit more what the application error exactly is and what you expect
FPM to do. Also could you attach your FPM config.
From the description it seems to me like you might have an idle process but not really sure. If
that's the case, have you tried setting pm.process_idle_timeout?
Previous Comments:
------------------------------------------------------------------------
[2019-02-06 19:47:19] requinix@php.net
Maybe I was mistaken but it sounded originally like you were saying that everything between Apache
and PHP works fine unless you add a load balancer. Now you're saying that everything between
the LB and Apache works fine unless you add PHP?
------------------------------------------------------------------------
[2019-02-06 11:21:31] martin dot barker at thisisbeacon dot com
https://s3-eu-west-1.amazonaws.com/beacon.media/martin_captures.pcap
------------------------------------------------------------------------
[2019-02-06 11:09:59] martin dot barker at thissibeacon dot com
So just to be clear 2 members of staff at our side 2 AWS Engineering staff all looking into this
problem for 4 hours.
We had tcpdump running, a static apache (HTML) site was working the whole time. so this was only
happening when php was being used.
how we identified this was from the tcpdump we could see everything from the load balancer to the
server was working.
We could even see the server was sending the output content from PHP-FPM as it was created.
The only problem was that the PHP-FPM handle waited for the socket timeout to occur Default of 60
seconds even though it has finished execution of the files.
However, when the WordPress does not have a DB error it does not do the same site loads and
responded in under 2 seconds.
So unless you're telling me that there is a bug in the Most Used PHP Application in the world
in a specific case it errored created the output then but the process to sleep for more than 60
seconds before closing the connection.
This is a PHP Bug, Apache2 works without PHP no Problem Apache2 is using the PHP Connector in FPM
Mode. every part of where this error could be coming from is PHP Projects Code.
------------------------------------------------------------------------
[2019-02-06 10:54:39] martin dot barker at thisisbeacon dot com
Wait your telling me a PHP Application not responding correctly is not a bug...
So what your deliberately leave the connection to apache2 open when it a handled error happens, even
though no error it closes the connection correctly?
------------------------------------------------------------------------
[2019-02-06 02:30:14] requinix@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system
is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Besides the fact that the problem clearly appears to be with the LB, this is too complicated to deal
with on a bug tracker. Too many variables. If you can eventually track down the problem to something
specifically with php-fpm (which has no knowledge of your LB because Apache is in between) then we
can work from there.
------------------------------------------------------------------------
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=77574
--
Edit this bug report at https://bugs.php.net/bug.php?id=77574&edit=1