This is to allow more time to switch for active to idle in scoreboard as
it seems that Travis is quite short on resources and might not switch it
quickly enough.
SaltStack uses Python subprocess and redirects stderr to stdout which is
then piped to the returned output. If php-fpm starts in daemonized mode,
it should close stderr. However a fix introduced in GH-8913 keeps stderr
around so it can be later restored. That causes the issue reported in
GH-9754. The solution is to keep stderr around only when php-fpm runs in
foreground as the issue is most likely visible only there. Basically
there is no need to restore stderr when php-fpm is daemonized.
This change primarily splits SAPI deactivation to module and destroy
parts. The reason is that currently some SAPIs might bail out
on deactivation. One of those SAPI is PHP-FPM that can bail out on
request end if for example the connection is closed by the client
(web sever). The problem is that in such case the resources are not
freed and some values reset. The most visible impact can have not
resetting the PG(headers_sent) which can cause erorrs in the next
request. One such issue is described in #77780 bug which this fixes
and is also cover by a test in this commit. It seems reasonable
to separate deactivation and destroying of the resource which means
that the bail out will not impact it.
Adds a setting "access.suppress_path" to php-fpm pool configurations
which causes successful GET requests to the specified URIs to be
excluded from the access log. This is to reduce noise caused by
automated health checks.
Requests with response codes outwith the successful range 200 - 299,
requests made with query parameters and requests which have a
Content-Length other than 0 will ignore this setting as a security
precaution.
Closes GH-8174, #80428 [1]
[1] https://bugs.php.net/bug.php?id=80428
This issue might happen if there is change of the fcgi stream when
the buffer is full. Then the empty record is created which signals
end of stream which is incorrect.
The actual fix without a test was contributed by GitHub user @loveharmful
in GH-3198.
This change introduces subsequent kill of the process when idle process quit
(SIGQUIT) does not succeed. It can happen in some situations and means that FPM
is not able to scale down in dynamic pm. Using SIGKILL fixes the issue.
