Changing NUT daemon debug verbosity

Overview

Table of Contents

• Current development version (future NUT v2.8.1+)
• NUT v2.8.0
• NUT v2.7.4 and older

NUT programs emit many messages to trace progress and provide other hints as deemed needed by developers and other contributors, with somewhat arbitrarily assigned verbosity levels for each message: 0 being (almost) silent, 1 being the top-level overview of activity, and greater numbers adding more levels of detail (or noise). When NUT programs are started, a debug verbosity level can be configured by command-line arguments or other means (depending on NUT version), which means that messages with that or lower (closer to 0) level become visible on standard error channel and/or syslog.

The way to configure the verbosity setting depends on NUT version: with 2.8.0 or newer (e.g. custom builds) there are debug_min NUM settings for ups.conf, upsd.conf, upsmon.conf so it suffices just to edit the suitable config and reload/restart the daemon. For 2.7.4 and older releases, you have to edit their init-scripts or systemd units to add a -D parameter for one more level (max practical verbosity is 6, so -DDDDDD is common) and keep in mind that debug enabled via command-line puts the program into foreground mode (you may have to add & in init scripts, change Type in systemd units, etc.)

Current development version (future NUT v2.8.1+)

Since issue #1903 and a series of later pull requests, there is limited support for driver reloading to change configuration of running daemons for options which are known to not require thorough re-initialization — including the debug_min verbosity setting. This is integrated with the new drivername -c reload* and upsdrvctl command-line options, as well as with nut-daemon-enumerator script and service (systemd, SMF) which would previously only support restarting a driver if its configuration has changed.

From development perspective, this is supported via signals (POSIX builds) and Unix-socket/Windows-pipe protocol intended for driver to data server chatter.

Also since PR #1915, numerous daemons (upsd, upsmon, drivers, upsdrvctl, upssched) which accepted -D option for debug setting previously, now can also honour a NUT_DEBUG_LEVEL=NUM environment variable if no -D arguments were provided. Unlike those arguments, the environment variable does not enforce that daemons run in foreground mode by default.

NUT v2.8.0

Since PR #683 many NUT daemons support a debug_min NUMBER setting (with upper-/lower-casing to match other keywords in respective configuration files) which allows to set a non-zero initial debug verbosity for the respective program, without affecting the fore-/back-ground mode. That effort also added explicit -F and -B CLI options to many daemons, to request a fore-/back-ground mode explicitly, with default behavior remaining backwards-compatible (go to background unless debugging).

In particular, this allows to (temporarily) change verbosity for production services without editing or otherwise impacting their service methods, init-scripts, etc. For upsd and upsmon daemons (but not for drivers) the -c reload activity or equivalent reaction to SIGHUP should take the modified setting into account "on the fly".

NUT v2.7.4 and older

A typical change to bump debug verbosity would look like this:

• …​for init-scripts:

 start)
-    /usr/local/ups/bin/upsd
+    /usr/local/ups/bin/upsd -DDDDDD &
     ;;

• …​for systemd units you are encouraged to add a drop-in configuration file to override original lines, but it is technically possible to edit the original unit files for short-lived changes. In either case, don’t forget to systemd daemon-reload after editing and before restarting the unit. The effective change would be like:

-Type=forking
-ExecStart=/usr/local/ups/bin/upsd
+Type=simple
+ExecStart=/usr/local/ups/bin/upsd -DDDDDD