daemons lack a -q (quiet flag)

[gdt]

Preferences differ, but now there is no approach for people that think daemons should print (stdout/stderr) only things that are noteworthy (critical or an error) or specifically requested. This is a feature request to add -q to drivers/upsd/upsmon/upslog so that it is quiet absent critical/error/requested.

For a longer discussion, see #1782.

[jimklimov]

Does make sense (per that discussion), although a mixed -q / -D processing could raise eyebrows (is quietness effectively a negative debug level value?) :)

As mentioned in that discussion, on the technical side there is a complication that NUT programs print the banner before handling the CLI arguments and config files (which can set the debug levels), and might abort during that (e.g. because of unknown args). With the banner always being before further messages, understanding who complained and why is easier.

Either programs would have to be adjusted to print the banner whenever they abort during CLI/config processing (register some atexit() handling of a print-once routine for deeply nested calls?), or perhaps an environment variable can be introduced that can be set for init scripts and similar integrations, but not impacting command-line use. Consulting an envvar would have minimal impact on existing code structure (including backwards-compatibility - currently released programs would refuse to run with scripts that ask for an unknown -q option, but would not abort if an unsupported envvar is in the env).

[jimklimov]

See also #1667 for similar solution precedent to a similar issue.

And #316 for the opposite opinion.

[gdt]

I vote for using -v for verbose and making -q default, which avoids the quiet/debug fighting.

As for #1667, I hope ssl was only initialized if the user asked to do something ssl-ish.

[gdt]

Also, about banner: It is very rare for daemons to print version to stdout/stderr. The standard approach is to daemoize and log a "foo started" at LOG_INFO. That might as well have the version. Certainly if there's a problem that prevents daemonizing, that's fair on stderr

Another common pattern is to have --version or -V to print the version (and do nothing else). With that, there's no need to print the version if the arguments are invalid, so the whole "when to print the banner" becomes moot.

[jimklimov]

In PR #2568 among other things I'm trying a balanced envvar-based approach (so easy to stick into wrapper scripts, shell profile, nut.conf, etc.) with a new support for an export'ed NUT_QUIET_INIT_BANNER=true toggle. As part of this work, some programs were identified that unilaterally printed the banner as soon as they started, before processing CLI options and possibly failing at that:

• upsdrvctl - 65250a9
• upslog, upsmon, upsd and drivers (main.c) - 06be3c8

Several other programs only print it with the -V option, in help/usage, or debug streams.

Troubleshooting-wise, I rule in favor of having it available by default, since it already takes days of turnaround in issue discussions to pull such details as "which NUT version are you complaining about?" with many users. Some have little way to know that without a lot of spelunking -- using embedded builds, HA plugin containers, etc. Having the string in their screenshots or log excerpts helps a lot.

But deployments run by power-users who are annoyed by these banners can now be made quieter with a single line in their NUT configs or shell profiles.

@gdt: WDYT, can the issue be deemed resolved by this approach? :)

[gdt]

You are the BDFL, so it's your call.

But I think programs should not print these by default, and that's what -V or --version is for (and fine for it to be in the on-error usage output). The fact that users submit terrible bug reports is not a good reason to burden others with noise or ask them to do something which I view as kludgy.