-
-
Notifications
You must be signed in to change notification settings - Fork 432
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-reloadafter 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:
- Finding recent development iteration artifacts
- Building NUT for in-place upgrades or non-disruptive tests (including the build prerequisites for different platforms in-tree or as a rendered page on NUT website) 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
upsdrvctldrivers 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.