[Nut-upsdev] logging strategy
Greg Troxel
gdt at lexort.com
Sun Jan 15 17:46:48 GMT 2023
Jim Klimov <jimklimov+nut at gmail.com> writes:
> I don't think there is any particular strategy, at least not one I'd know
> of either :) So it is mostly ad-hoc, to keep smaller verbosity numbers
> reasonably quiet, and sufficient info to see the logic progression at a
> given debug level (e.g. if major milestones of a routine are logged at
> level N, further traces like "I saw value X here" would be N+1 or more).
> De-facto verbosities fizzle out at 6, but generally it is an int value,
> so...
Sounds good - what I wrote down as a plan for bestfortress very much
matches that, 1 to 5 where 5 is if you want to see every IO byte.
> Regarding syslog/stdout/stderr, the upsdebugx*() methods are defined here
> and near:
> https://github.com/networkupstools/nut/blob/ad70749f243527e774c3f03a08228430143396e9/common/common.c#L1205
> and end up calling vupslog() at which can report to stderr (not stdout)
> and/or syslog, based on settings - see around
> https://github.com/networkupstools/nut/blob/ad70749f243527e774c3f03a08228430143396e9/common/common.c#L1011.
> The UPSLOG_STDERR bit is set by default, but cleared in the background()
> method, along with raising the UPSLOG_SYSLOG bit. By default enabled debug
> means staying foreground, so the bits are not changed. However "recently"
> the explicit -F/-B flags were added to manipulate fore-/back-grounding
> independently of debug (default behavior remains as it was).
ack, makes sense.
> Note that daemons started under service management frameworks like SMF or
> systemd can remain in "foreground" mode (with backgrounding handled by
> framework forking itself), so continue logging to stderr with messages
> landing into systemd journal or SMF service-instance log file.
ok - netbsd doesn't do that (expecting things to daemonize and use
syslog), but good to know.
> A few programs are more explicit about this, e.g.:
> ````
> :; git grep -n syslogbit_set
> common/common.c:130:void syslogbit_set(void)
> include/common.h:234:void syslogbit_set(void);
>
> clients/upssched.c:1341: syslogbit_set();
> drivers/main.c:1052: syslogbit_set();
> server/upsd.c:1827: syslogbit_set();
> ````
I did find that in drivers/main.c.
> So upsdebugx should therefore 1) not have the driver name and 2) should
> have a function, for things that aren't clearly locatable. Correct?
>
> 1) I don't think it prints a driver name (at least not by itself - maybe
> some drivers or other programs pass format strings which hardcode such
> stuff).
I was confused; syslog on my system is printing the program name.
> 2) a common incantation is `upsdebugx(NUM, "%s: some text", __func__);` to
> take advantage of modern compilers providing the __func__ macro.
> Technically also __FILE__ and __LINE__ may be used. Neither is guaranteed
> across the portability board however, but that is likely to only bite very
> old systems nowadays. The `configure` script tries some fallbacks for
> __func__ but not for others.
Thanks - I may try that, but I think I'm trying to write debug
statements that are sort of human readable without code refs and also
easily findable in the code.
But ack that __func__ is acceptable.
> As for s_upsdebug_ascii() - I do not think it is a perfectly good idea to
> change it (maybe is - not much used in NUT codebase; but possibly some
> forks have more use for it).
> It sounds reasonable however to define and implement a different method for
> this purpose, when you expect that sort of content - and call it where
> suitable.
>
> Maybe makes sense to create a typical hexdump printer along the lines of
> https://gist.github.com/jimklimov/07913a3e30a7d7ec50e9c946117c994f#file-jenkins-credump-L17-L41
> (that particular code is groovy, but trivial to convert elsewhere).
I want to see mostly-ascii as mostly-ascii with escapes, because that's
what Fortress output smells like so far, rather than flipping to all
hex (if I read groovy right).
Totally fair point about not changing s_upsdebug_ascii (but I think we
shouldn't worry about forks as socially they should contribute back). I
will just add a new s_upsdebug_escapedascii and friends -- works for me.
More information about the Nut-upsdev
mailing list