Open tormodvolden opened 2 months ago
As a quick shot with existing builds - does it suffice to export the envvar in USB-capable driver units/init-scripts (commonly via nut.conf
)?
For later iterations, I'd envision something like what's done in recent years for nut_debug_level
via DEBUG_MIN
settings and real-time protocol settings to dial the knob in-vivo.
"Per context" here maps to one process's usage of libusb (from init to close), right?
Yes, if there is a mechanism to set environment variables when executing the driver binaries, that will work.
Setting the env var on the command line when launching a program is technically easy but there are syntax differences between operating systems (or rather their shells), and when things e.g. run via systemd it becomes more difficult for many end-users.
Per-context refers to the libusb concept of context. You can have multiple libusb contexts in one process without them interfering with each other. They will for instance have their own list of discovered devices and their own set of callbacks for events, their own debug level and so forth. This makes sense e.g. for a larger program with plugins or modules that do USB but operate independently.
Got it, thanks!
For starters, linking docs to https://libusb.sourceforge.io/api-1.0/group__libusb__lib.html#ga2d6144203f0fc6d373677f6e2e89d2d2
Made a quick improvement via docs; a configurable/run-time "knob" may be on the table some time in the future, so I would keep this issue open.
exported LIBUSB_DEBUG = 4
is not working yet ?
For environment variable setup through nut.conf
file sourced for service startup (including drivers as a service - but not used directly as a program nor via upsdrvctl
), either way - for a shell interpreter you would
export LIBUSB_DEBUG=4
Not exported
, no spaces around =
...
For environment variable setup through
nut.conf
file sourced for service startup (including drivers as a service - but not used directly as a program nor viaupsdrvctl
), either way - for a shell interpreter you wouldexport LIBUSB_DEBUG=4
Not
exported
, no spaces around=
...
In nut plugin setup config all settings with spaces, but not a problem I can check both with and without spaces. So libusb debug work with debug_min=6 also?
We here are making NUT, not its HA plugin, sorry ;)
From what I saw, it is set up by yaml files that NUT *.conf
files get generated from, not by editing NUT configs in UI directly. Maybe you should "cut out the middleman" and run NUT programs directly while investigating?..
AFAIK the plugin uses packaged (or custom-built, per wiki) NUT binaries and scripts etc., so maybe you can inject the EnvironmentVariable=LIBUSB_DEBUG=4
to the nut-driver@.service
definition temporarily - assuming plugin rewrites nut.conf
so you can't really edit it (and chattr
to make it immutable is not helpful either)?..
And "no", the debug_min
setting for NUT verbosity is not currently linked to libusb's own debug. Perhaps adding it as a setting to be recognized from ups.conf
and causing a setenv()
early in drivers/main.c
(rather than diligent setting of libusb context verbosity, as proposed in that issue originally) is also a decent quick solution.
We here are making NUT, not its HA plugin, sorry ;)
From what I saw, it is set up by yaml files that NUT
*.conf
files get generated from, not by editing NUT configs in UI directly. Maybe you should "cut out the middleman" and run NUT programs directly while investigating?..AFAIK the plugin uses packaged (or custom-built, per wiki) NUT binaries and scripts etc., so maybe you can inject the
EnvironmentVariable=LIBUSB_DEBUG=4
to thenut-driver@.service
definition temporarily - assuming plugin rewritesnut.conf
so you can't really edit it (andchattr
to make it immutable is not helpful either)?..And "no", the
debug_min
setting for NUT verbosity is not currently linked to libusb's own debug. Perhaps adding it as a setting to be recognized fromups.conf
and causing asetenv()
early indrivers/main.c
(rather than diligent setting of libusb context verbosity, as proposed in that issue originally) is also a decent quick solution.
Sure, You are 100% right. BTW, I'm on Unraid plugin for NUT not HA :).
Oops :)
To investigate USB issues it is important to see the debug output from libusb. Either the env var LIBUSB_DEBUG must be set to e.g. 4, or the program can call libusb_set_debug() to set debug level per libusb context.