This happens because config test does not shutdown SAPI.
In addition this commit also fixes few failures when running FPM tests
under root.
Closes GH-10296
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.
If an installed php.ini turns expose_php on/off, and an FPM pool
overrides that with php_flag[expose_php]=off/on, a status pool
created with pm.status_listen in a pool config will have its expose_php
reflect the php.ini value, and not the pool config's override.
This change looks for an override set in
php_flag/php_value/php_admin_flag/php_admin_value and carries that
through.
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.
Jakub Zelenka