search for: debug_min

Cheers, With https://github.com/networkupstools/nut/pull/1906 and https://github.com/networkupstools/nut/pull/1912 (and probably some more later), I've been enhancing NUT driver framework with support for live reload of configuration, primarily to acknowledge changes to debug_min setting in ups.conf - but made in a generic fashion that specific drivers may take advantage of for their `addvar`'ed options handling (as a separate effort from users/maintainers of those drivers). Live testing and other forms of review would be welcome :) Jim -------------- next part ----...

Cheers, With https://github.com/networkupstools/nut/pull/1906 and https://github.com/networkupstools/nut/pull/1912 (and probably some more later), I've been enhancing NUT driver framework with support for live reload of configuration, primarily to acknowledge changes to debug_min setting in ups.conf - but made in a generic fashion that specific drivers may take advantage of for their `addvar`'ed options handling (as a separate effort from users/maintainers of those drivers). Live testing and other forms of review would be welcome :) Jim -------------- next part ----...

...-driver-enumerator (NDE) script had a regression which caused it to not reload nut-driver instances (systemd, SMF) when `ups.conf` edits happened. * on a related note, it may be possible that "live" driver reloading (at least on master branch) does not reduce debug verbosity to zero when `debug_min 0` is active in its `ups.conf` section. Increasing verbosity and decreasing to non-zero (e.g. 1) works. These are currently being investigated. Jim Klimov On Tue, Apr 2, 2024 at 1:06?AM Jim Klimov <jimklimov+nut at gmail.com> wrote: > Hello all, > > After a prolonged labour w...

...-driver-enumerator (NDE) script had a regression which caused it to not reload nut-driver instances (systemd, SMF) when `ups.conf` edits happened. * on a related note, it may be possible that "live" driver reloading (at least on master branch) does not reduce debug verbosity to zero when `debug_min 0` is active in its `ups.conf` section. Increasing verbosity and decreasing to non-zero (e.g. 1) works. These are currently being investigated. Jim Klimov On Tue, Apr 2, 2024 at 1:06?AM Jim Klimov <jimklimov+nut at gmail.com> wrote: > Hello all, > > After a prolonged labour w...

Hello all, After a prolonged labour with a few re-issues of the tag and many pushes during the day, NUT v2.8.2 was found in a strange egg by a bunny hopping away from the April fools. All that - blessed under the shine of Polar lights in the middle of the icy North Ocean. A python module was released but slipped away with an earlier commit. Other artifacts should follow shortly. Jim Klimov

Hello all, After a prolonged labour with a few re-issues of the tag and many pushes during the day, NUT v2.8.2 was found in a strange egg by a bunny hopping away from the April fools. All that - blessed under the shine of Polar lights in the middle of the icy North Ocean. A python module was released but slipped away with an earlier commit. Other artifacts should follow shortly. Jim Klimov

...osity mode, it historically defaults to staying foregrounded for easier Ctrl+C etc. NUT 2.8.0 should include -F/-B explicit options for some daemons (though not upsdrvctl wrapper - that was added/fixed on master recently), so you can e.g. run drivers backgrounded and verbose. It also includes "debug_min" settings via ups.conf global or per-device sections, and via some other daemon configs. With raised verbosity, you would see lines about setting dstate entries with readings at least. I think you interrupted the sent log too early, it might have completed the initialization a few seconds lat...

...osity mode, it historically defaults to staying foregrounded for easier Ctrl+C etc. NUT 2.8.0 should include -F/-B explicit options for some daemons (though not upsdrvctl wrapper - that was added/fixed on master recently), so you can e.g. run drivers backgrounded and verbose. It also includes "debug_min" settings via ups.conf global or per-device sections, and via some other daemon configs. With raised verbosity, you would see lines about setting dstate entries with readings at least. I think you interrupted the sent log too early, it might have completed the initialization a few seconds...

Normally yes - enable and start the target and the particular services relevant to your setup. For the binary you have from packaging (if not rebuilt as suggested earlier), set debug_min=3 in ups.conf section for upscode2, to currently trade driver viability for some storage traffic with more logs :\ Sorry about that, Jim On Wed, Jul 5, 2023, 02:29 Karl Schmidt <karl at lrak.net> wrote: > Ok - I'm wondering is this is a systemd config bit? > > systemctl restar...

On 7/4/23 10:01PM, Jim Klimov wrote: > Normally yes - enable and start the target and the particular services relevant to your setup. > > For the binary you have from packaging (if not rebuilt as suggested earlier), set debug_min=3 in ups.conf section for > upscode2, to currently trade driver viability for some storage traffic with more logs :\ > > Sorry about?that, > Jim OK - this is strange . If I run it WITH the debug - it works - WITHOUT - it fails. Put debug back in and it works again.. With debug I ca...

...Schmidt <karl at lrak.net> wrote: > On 7/4/23 10:01PM, Jim Klimov wrote: > > Normally yes - enable and start the target and the particular services > relevant to your setup. > > > > For the binary you have from packaging (if not rebuilt as suggested > earlier), set debug_min=3 in ups.conf section for > > upscode2, to currently trade driver viability for some storage traffic > with more logs :\ > > > > Sorry about that, > > Jim > > OK - this is strange . If I run it WITH the debug - it works - WITHOUT - > it fails. Put debug back in...

...the memory lane with another device with Richcomm-based hardware, and ultimately nutdrv_qx driver happened to support that one: https://github.com/networkupstools/nut/issues/2395 Some key take-aways were: * try starting the driver with bumped debug verbosity (e.g. from command line, or using a `debug_min` setting with NUT v2.8.0 and newer) to know better what it probes and how it fails; * if the device uses a serial port connection (maybe over a USB link, but with a chip that presents as a serial port for the OS) be sure to specify the appropriate `port=/dev/...` line in the NUT driver configuratio...

Heya, first time posting to a mailing list so please excuse me if I do something wrong :) I'm new to NUT and trying to get things working on my TrueNAS, I have a "Vultech 1500VA" UPS which comes with the software "PowerManager II" and it seems to be using the "richcomm_usb" driver. There are 5 devices in the compatibility list and I tried all of them, sadly to

...t lrak.net>> wrote: > > On 7/4/23 10:01PM, Jim Klimov wrote: > > Normally yes - enable and start the target and the particular services relevant to your setup. > > > > For the binary you have from packaging (if not rebuilt as suggested earlier), set debug_min=3 in ups.conf section > for > > upscode2, to currently trade driver viability for some storage traffic with more logs :\ > > > > Sorry about?that, > > Jim > > OK - this is strange . If I run it WITH the debug - it works - WITHOUT - it fa...

Ok - I'm wondering is this is a systemd config bit? systemctl restart nut-driver at malaysia.service Job for nut-driver at malaysia.service failed because the control process exited with error code. See "systemctl status nut-driver at malaysia.service" and "journalctl -xeu nut-driver at malaysia.service" for details. root at malaysia:~# systemctl status nut-driver at

...moment if it is a weak Wants or a harder Requires type of dependency there; technically `upsd` should run well without drivers and report that the device is unknown or data is stale). Probably you can interpolate the event trails from `dmesg` and `journalctl -lx` as suggested earlier, with bumped `debug_min` in `ups.conf`, `upsd.conf` and maybe `upsmon.conf`, to check if the real events and service state changes seem to confirm this theorized chain of events: * USB reconnection (HW/FW reasons can vary a lot); * `nut-driver at Eaton.service` tries to reconnect but fails, or for older versions just abo...

Jan 19 05:50:13 mars nut-monitor[849]: Signal 15: exiting Jan 19 05:50:13 mars nut-monitor[849]: Network UPS Tools upsmon 2.8.0 Jan 19 05:50:13 mars systemd[1]: Stopping nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller... Jan 19 05:50:13 mars systemd[1]: nut-monitor.service: Deactivated successfully. Jan 19 05:50:13 mars systemd[1]: Stopped nut-monitor.service