`ap_get_brigade()` may fail for different reasons, and we must not
pretend that a partially read POST payload is fine; instead we report
a content length of zero what matches all other `read_post()` callbacks
of bundled SAPIs.
Closes GH-10059.
There might be a moment when the child log event is executed after
freeing a child. That could possibly happen if the child output is
triggered at the same as the terminating of the child. Then the output
event could be potentially processed after the terminating event which
would cause this kind of issue.
The issue might got more visible after introducing the log_stream on
a child because it is more likely that this cannot be dereferenced
after free. However it is very hard to reproduce this issue so there
is no test for this.
The fix basically prevents passing a child pointer and instead passes
the child PID and then looks the child up by the PID when it is being
processed. This is obviously slower but it is a safe way to do it and
the slow down should not be hopefully visible in a way that it would
overload a master process.
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.
With request timeouts configured, php-fpm occasionally prints the
following warning:
WARNING: failed to acquire scoreboard
This is happens when php-fpm checks the child scoreboards for timeouts,
but fails to acquire a lock immediately. As this can (and does) occur
during normal operation, this commit downgrades this to a notice.
Closes#9019.
We revert the commits which caused this regression from the PHP-8.0 and
PHP-8.1 branches for now. We keep it in "master" because of PR #8833
which may offer a proper fix without BC break.
Extensions may (and do) write to stderr in mshutdown and similar. In
the best case, with the stderr stream closed, it's just swallowed.
However, some libraries will do things like try to detect color, and
these will outright fail and cause an error path to be taken.
