-
-
Notifications
You must be signed in to change notification settings - Fork 370
Changing NUT daemon debug verbosity
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.)
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.
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".
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
Welcome to the Network UPS Tools (NUT) project Wiki, and feel free to contribute tricks and insights.
While there are several good entries in the menu, ones referenced most frequently in issue discussions include:
- Building NUT for in-place upgrades or non-disruptive tests and Using NIT (NUT Integration Test suite) sandbox
- Technicalities: Customizing (NUT) config files and scripts delivered by packaging
- Links to distribution packaging recipes and repository sections
- Troubleshooting
upsdrvctl
drivers not starting ("insufficient permissions on everything" or "Can't claim USB device [VVVV:PPPP]@0/0: Entity not found") possibly due to nut-driver-enumerator (NDE) services having been there before you with NUT 2.8.x, and "insufficient permissions" when starting USB drivers for a different PoV on this; see also an example unit deployment detailed in NUT systemd service units page - Changing NUT daemon debug verbosity
- Building NUT integration for Home Assistant
- Running NUT in an LXC container
- Troubleshooting eventual disconnections (Data stale) and CyberPower Systems (CPS) know-how
- NUT for Windows
- NUT HCL and DDL
- Code contributions, PRs, PGP and DCO
- NUT CI farm
Also keep in mind the documentation links from NUT website and the FAQ in particular.