[Nut-upsuser] [Nut-upsdev] How verbose should NUT be by default?

[Tim Dawson]

My take is virtually silent in normal operation. A brief startup message, and then nothing more that critical/fatal errors and major events/state changes. If something happens, the user/admin can turn up debug to capture the next fault (and if there isn't, then nothing to debug). Horrific amounts of jibberish and spew to logs under normal operation serve no purpose, make logs harder to parse, and consume disk space. Oh, and one other option may be to be able to alter the debug level while running, as is the case in a lot of other system level software.

Just my $.02 . . . 

- Tim

On January 9, 2023 10:56:58 AM CST, Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> wrote:
>Hello all,
>
>  During discussion of https://github.com/networkupstools/nut/issues/1782
>me and Greg uncovered a diametral difference of opinion about the verbosity
>of NUT programs in general, and of `upsmon -K` (checking for POWERDOWNFLAG
>during shutdown integration) in particular.
>
>  To me as a sysadmin type often (in the past at least) having to
>troubleshoot the tails and ends of systems' untimely (or unclean) demise,
>all info about it feels like useful clues. And often is.
>
>  Also NUT dealing in the business of cutting power to this computer, or to
>others, intentionally or by misconfiguration (e.g. by spouting garbage to
>serial ports that confuses an UPS that talks a different protocol), is a
>bit more "special" than numerous other programs, tools, daemons and
>services.
>
>  The opposite opinion is that programs should be quiet until asked to
>squeak (e.g. by restarting with higher debug verbosity... "that would help
>troubleshooting why the rack went down last week, right!" says the sysadmin
>me).
>
>  So here is a shout-out to other practitioners: should NUT programs print
>their banner and other info (e.g. competing daemon instance was/wasn't
>found and how that was determined) every time they start by default? Or
>should they indeed be revised to talk less (and then settings and
>init-scripts in packaging can be tweaked to retain current behavior should
>distros/users want to)? Note that an alternative is to redirect to
>/dev/null the messages in init-scripts and similar integrations instead.
>
>Jim

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230109/b505c863/attachment.htm>