This introduces an enum `fpm_init_return_status` to propagate the status
up to fpm_main. This also makes the code clearer by not using magic
integer return numbers.
Closes GH-10388
This changes the log level for an unknown child during wait as this is
not unuasual if FPM master has pid 1 and also possible in some cases
for higher pid processes. Based on that and the fact that this is not
really a problem, there is just a debug level message emitted for pid 1
and for higher pid a warning is emitted.
Closes GH-10319
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
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.
Remi Collet