similar to: Enhanced driver troubleshooting

...it was almost midnight, Cinderella became a pumpkin, and NUT was released!.. Trick or treat?! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20231031/f3590340/attachment.htm>

...it was almost midnight, Cinderella became a pumpkin, and NUT was released!.. Trick or treat?! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20231031/f3590340/attachment.htm>

Jim Klimov <jimklimov+nut at gmail.com> writes: > By the way, on the NUT CI farm the libwrap is present on some (though not > all) systems - covering linux, freebsd, openindiana... and neither > complained about `sockdebug` :\ > > What version do you have? Maybe it is some alternate implementation? Looks like 7.4, as amended in NetBSD over the years. Looks like the

Errata coming up for NUT v2.8.2: * it was discovered that the nut-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

Errata coming up for NUT v2.8.2: * it was discovered that the nut-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

Hi Arnaud, Hi Scott, Hi list, Here is a patch to support the Zinto D from ONLINE USV-Systeme AG. I already sent a version to Russell Kroll (2006-04-09), without no response and I cannot find support for Zinto in svn until now. I found a discussion on this list about the Xanto from ONLINE, but the Zinto seems to use different commands. The commands are quite similar to those for Opti-UPS, so I

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

Thinking of it, the service-aware nut-driver-enumerator script has ways to set dependencies of a driver on other units in the system, depending on driver type. A couple of lines added there would be useful to ensure the failover/multiplex driver(s) start after the "real" driver units they scrape data from, and it would be a "soft" dependency (real driver unit may crash without

By the way, on the NUT CI farm the libwrap is present on some (though not all) systems - covering linux, freebsd, openindiana... and neither complained about `sockdebug` :\ What version do you have? Maybe it is some alternate implementation? Jim On Thu, Nov 9, 2023 at 3:44?PM Greg Troxel <gdt at lexort.com> wrote: > I am (belatedly) updating pkgsrc to 2.8.1 (+ bugfix). > >

P.S. To articulate better what I am unclear about from your message: `nutshutdown` seems to run `@SBINDIR@/upsdrvctl shutdown`. >From my understanding, this would command - all - `ups.conf` UPS to shutdown. So this would already include the UPS monitored by any failover/multiplexing driver. In contrast, `upsdrvctl shutdown` would start up all these drivers again, respectively. What kind of

Good point, I guess I thought it knew which UPSes are getting the FSD treatment. Maybe this should also get revised eventually (e.g. a "primary" monitoring system not fed by the UPS it is wired to should never FSD itself due to the outage, but should ensure that UPS gets powered off or power-cycled when no "secondary" clients remain). Then maybe not much is needed at this

Hi all, Yesterday?s PR #2945 got me thinking about my basic failover setup and raised some questions I didn?t want to derail the PR with?hope this is the right place to ask. Apologies if not. The PR includes this note: > NOTE: There is currently no support for "multiplexing" information or > commands for devices with multiple-media/multiple-driver access, e.g. to > gain

Thanks, I think it would not hurt to add the variables into the source if that helps? A bit puzzled why it wants TCP wrappers though, the program is primarily about the Unix socket access. It can be used by end-users or more likely by developers for troubleshooting; potentially for some automations that act like a NUT driver. Not intended as a prime-time mechanism, but could have its uses... As

Seconding ... or firsting, considering the recent call to testing hidden somewhere in a recent mail post ;) Currently I'm aiming at cutting a NUT 2.8.1 release during October. As a bit of self-imposed retrospective: I did hope for a faster (quarterly or so) cadence when I made the 2.8.0 release, but then a few issues came up as regressions of 2.8.0 and it became a sort of crusade to fix

Seconding ... or firsting, considering the recent call to testing hidden somewhere in a recent mail post ;) Currently I'm aiming at cutting a NUT 2.8.1 release during October. As a bit of self-imposed retrospective: I did hope for a faster (quarterly or so) cadence when I made the 2.8.0 release, but then a few issues came up as regressions of 2.8.0 and it became a sort of crusade to fix

On Fri, 28 May 2021, Jim Klimov via Nut-upsdev wrote: > ? Looking at NUT pull request (PR) history on GitHub, I see that we have > had a non-trivial number of stalled driver contributions sharing a prominent > similarity: proposed names for some of the variables did not fit into the list > defined at https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt > ? I

On Fri, 28 May 2021, Jim Klimov via Nut-upsdev wrote: > ? Looking at NUT pull request (PR) history on GitHub, I see that we have > had a non-trivial number of stalled driver contributions sharing a prominent > similarity: proposed names for some of the variables did not fit into the list > defined at https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt > ? I

>> Also the upsmon POWERDOWNFLAG fits into this question > I'm confused. That flag can't be persistent across reboots, can it? Well, there is little practical reason, if any, for an `/etc/killpower` (as it is commonly named) to exist when you boot. It also has a potential for confusion if not deleted, as we discovered in some recent discussion - e.g. due to no packaged NUT init

Great! Regarding libusb and nut-scanner, I think the *.so (exact) symlinks are part of *-devel packages. This was solved in NUT recently (maybe after 2.8.2 release already) by detecting and stashing the basename of realpath of the library present during build, so the exact *.so.X.Y.Z would be also tried. Also, nut-scanner now (in 2.8.2 IIRC) should not suggest the volatile bus/busport/device