Let php-fpm -tt dump info regardless of log_level

[dzuelke]

When using php-fpm -tt to dump the configuration, and the input config has a log_level of warning or error, then nothing will be printed.

This change temporarily changes the zlog level to notice, if necessary, to allow the output to be printed.

Notably, the "configuration file %s test is successful" output is not affected by this; it still obeys the configured log_level. That behavior can't be tested, however, as tester.inc's log helpers do not actually seem to work with the "invert" flag passed in.

Current behavior with log_level = notice:

$ php-fpm … -tt:
[26-Jan-2024 19:03:06] NOTICE: [global]
[26-Jan-2024 19:03:06] NOTICE: 	pid = …
…
[26-Jan-2024 19:03:06] NOTICE: 	log_level = NOTICE
…
[26-Jan-2024 19:03:06] NOTICE:  
[26-Jan-2024 19:03:06] NOTICE: [www]
[26-Jan-2024 19:03:06] NOTICE: 	prefix = undefined
…
[26-Jan-2024 19:03:06] NOTICE:  
[26-Jan-2024 19:03:06] NOTICE: configuration file … test is successful

Current behavior with log_level = warning:

$ php-fpm … -tt:

New behavior with log_level = warning:

$ php-fpm … -tt:
[26-Jan-2024 19:03:06] NOTICE: [global]
[26-Jan-2024 19:03:06] NOTICE: 	pid = …
…
[26-Jan-2024 19:03:06] NOTICE: 	log_level = WARNING
…
[26-Jan-2024 19:03:06] NOTICE:  
[26-Jan-2024 19:03:06] NOTICE: [www]
[26-Jan-2024 19:03:06] NOTICE: 	prefix = undefined
…
[26-Jan-2024 19:03:06] NOTICE:  

[dzuelke]

@bukka related discussion, but probably not a change for a patch release: the dumped config really should not be written as log lines (with time and NOTICE prefixes), and not to stderr (but instead to stdout).

For example, nginx -T or httpd -S behave this way - their config check status messages go to stderr, and the dumped config info goes to stdout.

This allows capturing of the dumped config cleanly using pipelines or redirects.

With the current php-fpm -tt behavior, one has to parse the log lines, and also discard potential log messages, such as the "test successful" notice after the dump (that's also printed when only testing, not dumping, which is fine).

[dzuelke]

@bukka as you can see, an explicit test to verify that the status message does not show up (because it's not warning level, and printed after the config dump) is commented out - the $invert option of FPM\Tester::expectLogNotice() doesn't seem to work.

[bukka]

I don't think this can be classified as a bug. I see it more like something that needs to be improved / better documented but essentially it is a feature. So it needs to target master.

As it is a feature I would prefer to just introduce new mode that will print it directly rather than using logger. Maybe we could do it if user specify -ttt as we already count them. That would keep -tt for BC and would be just a minor acceptable when more that 2 t are specified.

[dzuelke]

Hmh, yeah, that is an option. This discussion probably warrants a separate issue or PR; I'll see if I have time to whip up the changes sometime soon in a PR, otherwise, I'll make an issue at least to track it.

What do you think about just the change in this PR to ensure that a requested config dump is at least always visible, @bukka? That seems like a more straightforward "ergonomics" fix. Want me to target a different base branch?

Is it intentional, by the way, that in config test mode, the output goes to the main server error log file in addition to standard error?

[bukka]

I guess it was probably intentional but not sure what was the thinking to do that. I don't think we can change this as a bug fix though. And for master it would be safer to just use the new mode. I think that changing the log level in the way how it's done in this PR is a bit of a hack so I would rather not do that.