Got a community question at
https://github.com/networkupstools/nut/issues/2466 with at least two users
(and UPSes) in trouble.
Curiously, they identify as 067b:2303 Prolific Technology like a common
USB-Serial dongle brand. Experiments with blazer and nutdrv-qx got no
reasonable response from the
Cheers all,
Per https://github.com/networkupstools/nut/pull/2480 there seems to have
been a byte-order bug in usbhid-ups subdriver for Powercom that precluded
it from shutdowns.
I am not fully certain if the problem (or the fix) are
endianness-dependent, so would welcome testing of that PR
Normally you should elevate to run e.g. `sudo upsdrvctl ...` so the NUT
driver program initializes as `root` and drops privileges to `nut`
(tweakable as the `user=...` in ups.conf, like your RUN_AS_USER in
upsmon.conf) soon after that, and default permissions on packaged files
expect that.
Hello all,
During discussion for development of a new driver, an old thought came to
my attention that we have a potentially insecure approach with some parts
of the codebase working with string and "var arg list" manipulation, which
use dynamic `char *` variables instead of fixed strings (or
Thinking of it, one purpose of upssched is to delay reaction to short-lived
flukes (e.g. if we go on battery for 20 seconds and set a delay for 30, if
we're back on line within that time frame, it is ok to go on living).
I wonder if your UPS went under 70% and you aborted the experiment too
early
Hello, and welcome (again) :)
> ...That [driver] executable will talk to the hardware in whatever way it
sees fit, and to nut over the UNIX socket/pipe. It does sound
architecturally feasible, at least, no?
This is more or less what NUT drivers themselves do, so yes - quite
feasible.
Hello all,
I think there was a very good reply about an Arduino-based controller for
a DIY UPS here. The project you posted to, with an Arduino presenting as a
Megatec protocol server, also seems interesting.
Here I'd like to reply to one point not covered before - DMF. As a short
and quick
y code sense the DC voltage.
>
> * External ADC: ADS1115 board. I wanted higher resolution DC voltage
> detection.
>
> My code then changed to take readings from the ADS1115 and convert that
> into a rough "50-100% capacity remaining" that I can report to NUT. It to
I agree with earlier posters, such documentation can help future tinkerers.
There is probably more than just one to hold the hand and walk through the
ordeals :)
Perhaps a new page at https://github.com/networkupstools/nut/wiki can be a
good location...
Jim
On Thu, May 16, 2024 at 1:29 PM Bill
FWIW, added this to Wiki:
https://github.com/networkupstools/nut/wiki/Monitoring%E2%80%90only-NUT-clients
On Thu, May 2, 2024 at 11:57 AM Jim Klimov wrote:
> Hello, and welcome to the NUT community! :)
>
> On one hand, it would generally help to read up the documentation about
> NUT
Hello, and welcome to the NUT community! :)
On one hand, it would generally help to read up the documentation about
NUT architecture, seeing as it is a crucial part of your systems' uptime
and data integrity.
On another hand, for this particular use-case: it is quite possible to
set up
Just in case, to the last couple of posts speaking of multiple listeners:
NUT does allow specifying several lines of `LISTEN host port` to handle
multi-homing and whatnot. A reminder to readers who might not realize this
possibility exists already.
Jim
On Tue, Apr 30, 2024, 18:00 Kelly Byrd
Thanks for sharing your take on this. (Sorry about likely mixing historic
standards, was not in position to cross-check while posting)
Just to clarify: using a different port *is* possible since forever, with
`LISTEN host port` (as two arguments to the directive); the question was if
having a way
Cheers all,
A recent discussion in the issue tracker brought up the idea to allow the
`LISTEN` keyword to also accept a single "host:port" token (e.g. if there
is only one argument, with at least one colon, and the last colon is
followed only by numbers, split it into host and port) :
UPDATE: No problem got confirmed about driver code - only some scripting
mishaps with NDE: https://github.com/networkupstools/nut/pull/2413 (testing
welcome)
Jim
On Fri, Apr 19, 2024 at 2:07 PM Jim Klimov wrote:
> Errata coming up for NUT v2.8.2:
>
> * it was discovered that 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
Just the sig file.
On Sun, Apr 7, 2024, 15:45 Greg Troxel via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Jim Klimov via Nut-upsuser writes:
>
> > A hiccup was reported about validating the tarball signature on some
> > systems, so it was reissued
A hiccup was reported about validating the tarball signature on some
systems, so it was reissued from another workstation. Please don't worry :)
Jim Klimov
On Tue, Apr 2, 2024, 01:06 Jim Klimov wrote:
> Hello all,
>
> After a prolonged labour with a few re-issues of the tag and many pushes
>
Well, for a bit of devil's advocate - if the battery swelled, it might hace
leaked or fumed, contaminating the device and contacts.
The safe approach (for their liability, and for end-users' fire hazard
really) is to not claim the device is safe to use anymore.
Jim
On Tue, Apr 2, 2024, 07:11
I suppose you have to ask on HA (or NUT plugin) forums. NUT itself is not
localized.
Jim
On Tue, Apr 2, 2024, 03:19 Roland Scheffer via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Hello,
>
> based on
>
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
Cursorily, your two LISTEN directives for same IP address can be
conflicting (one grabs the port another one wants)... And/or some service
dependencies (After/Wants/Requires in systemd) in your package are not set
up to start nut-server after surely having passed the network-online
milestone and
Hello all,
I think I've found the "regression" in Belkin/Liebert USB HID support
which worked for NUT v2.7.4 and reports zero voltages in 2.8.0 -- it was
actually caused by a bug fix: practically the only functional difference
per `git diff v2.7.4..v2.8.0 drivers/belkin-hid.c` is a change from
Hi,
FYI: I'll be away from computers (and possibly internet) for a couple of
weeks.
As for the logs, they are not "the same": the first one (with NUT 2.8.x)
failed to connect to the device it liked -- "failed to claim USB device:
Resource busy" (probably another program holds it, maybe a
Thanks again.
So one more bit (other than indeed different libusb versions) that could
potentially come into play is bitness - armv7l builds are 32-bit, right?
One idea from here is to have you run the driver programs directly with
high debug verbosity, e.g. `usbhid-ups -DD -s Liebert`
Thanks.
Can you please also check (e.g. with ldd `which usbhid-ups`) which
`libusb` variant (1.0 or 0.1) was the 2.7.4 version of the driver running
with?
I wonder if the two generations of that library got something
differently?..
The commit I mentioned -
Hello,
For clarity: what changed with the move from NUT v2.7.4 to 2.8.0 - the
warnings "became reported", or the highlighted values became zeroes (and
were valid non-zero numbers with older NUT - so a regression)?
It seems the message is specific to the subdriver and comes from commit
Hello all,
By some criteria (like known squashed bugs and regressions, or added
features) it is always high time to cut a NUT release, even if backlog and
pending nice-to-haves are looming well over horison. Missed 29.2. "the
neverday issue", but upcoming 3.14. "pi day" also looks like a fun
That is odd.
I suppose you ran not quite "autogen.sh, make, make install" but
"autogen.sh, *configure*, make, make install", with the "configure" part
taking a ton of options to tune for your system. There are no particular
options for `upssched`, or put another way, at least it would get built
To me, this line is suspect:
libusb1: Could not open any HID devices: insufficient permissions on everything
it seems like USB permissions on the host do not allow the NUT run-time
user (nutty?) to own the device filesystem node.
Check the upower/udev/... settings relevant there.
According to
Hello,
Hard to say for sure, devices are all different. But from general
experience, some thoughts may be relevant:
1) I've seen some UPSes return different battery charge levels or remaining
runtimes when they are running off wall power or just after switching to
battery. It may be that some
Hello, and thanks for the detailed report.
Regarding /var/run/nut - I think `systemd-tmpfiles --create` should have
taken care of this. Can you check if your tarball "package" actually
shipped a /usr/lib/tmpfiles.d/nut-common-tmpfiles.conf file, and does it
list (/var)/run/nut among the items
I sometimes get replies that are directed only to me.
Oftentimes it is a sender "error" to not have used Reply to All, so I
direct my response back to the list. Rarely it is about something the
senders deem confidential, where a pointed reply seems to make sense
(overriding would be bad).
Other
Hello, thanks for the details although I too am not sure about the "invalid
parameter" - got neither reasons nor solutions at the moment.
Regarding the "device: unknown", there was an issue in the USB matcher code
that did not let the driver "remember" the value it saw from libusb (and so
it
Hello and welcome!
My guess would be that a nut-driver service unit (or instances thereof
since NUT v2.8.0, monolithic before) have started and captured the devices,
so your attempts with another copy of the driver started from CLI fail at
that. Normally drivers detect an older sibling running
[D2] Device matches
>>0.418416 [D2] Reading first configuration descriptor
>>0.418456 [D2] failed to claim USB device: Resource busy
>>0.418487 [D2] Kernel driver already detached
>>0.418512 [D2] failed to claim USB device: Resource busy
>>0.418546 [D2]
Well, at least per issue tracker, they can be finicky especially regarding
reconnects (in many models, the USB controller tends to fall into
power-saving at the wrong times, so polling rates should be increased).
More on the Wiki and in github search/labels :)
As for Eatons, I've had experience
One more idea, inspired by messages systemd sometimes gives:
* Select to "Copy" the timestamps of when e.g. your `nut-server.service`
stopped/restarted;
* As root(!) run `journalctl -xl` for a detailed log with service state
changes and reasons, and other details, piped into `less` by default
*
> 1) How do I make the nut-server and nut-monitor find the right pid files?
They are there but it seems they can't be opened. Permissions are nut/nut.
Actually, if the preceding lifetime of the service was a graceful stop, the
exiting daemon should have removed its PID files. Then the newly
e. Can you recommend a small UPS (1
> > >Server) that is guaranteed to work flawlessly with NUT?
> >
> > perhaps Eaton Ellipse would be fine.
> >
> > The message above does not look like a problem of the UPS.
> > Was there anything other in the logs, before the
n 19, 2024 at 9:36 AM Matus UHLAR - fantomas
wrote:
> On 19.01.24 09:00, Jim Klimov via Nut-upsuser wrote:
> >Well, from your logs it seems that at 05:17:03 your nut-server (upsd)
> >restarted, so an upsmon reconnection attempt at 05:17:09 had an issue with
> >that (config
Well, from your logs it seems that at 05:17:03 your nut-server (upsd)
restarted, so an upsmon reconnection attempt at 05:17:09 had an issue with
that (config not all applied? strange a bit) but since 05:17:14 it is okay.
Maybe a few too many banners shown from upsmon, while its same uptime seems
I haven't used that package with Windows (haven't used that for a while) so
can't say directly. However I can't find, neither in sources nor in the
files stored in the MSI, the GUI program you've sent the screenshot from
and particularly the localization strings it uses. Are you sure it was not
a
Cheers all,
I would like to take a moment to wish everyone a happier New Year than
the few we've seen before, and hope for peace, quiet and joy for everyone.
We have had some good collaborations here, with new people and old guard
being engaged, more platforms confirmed and upkept by NUT CI
Well, it seems both apache and bash literally say they did not find an
executable there; it is not about NUT configs. Is the file present? (is
"spivey" same as "pi2" in "screenshots" posted?) Does it have the exec bit
set? Are all directories at least "executable" by apache user?
Jim
On Thu,
Hello,
Did you acquaint yourself with the NUT project? There are quite a few
architecture and installation documents and README's (maybe a few too many
for people just getting started, pull requests for simple entry points are
welcome) :)
In short, you would either have it installed via
Hello,
Hard to say from your "screenshot" but it seems like you're typing the
URL into command-line. Does your OS handle starting a browser for that?
Otherwise, you should run one manually and enter the URL there.
For that matter, did you follow the documentation on setting up the NUT
CGI
Cheers,
The current situation is a bit of a moving target - for USB devices you'd
need to custom build a `libmodbus` and then NUT against it. For more
details, see
https://github.com/networkupstools/nut/wiki/APC-UPS-with-Modbus-protocol
Hope this helps,
Jim Klimov
On Sun, Dec 10, 2023 at 3:01
Hello all,
as users of certain (primarily CyberPower and APC) devices know, some
firmwares report both "online" and "discharging" in some situations.
These depend on the device, vendor and firmware, but cases seen in
practice include:
* calibration (APC),
* being on-battery (CPS),
* having
>could not detach kernel driver from interface 0: Operation not permitted
Does that system have something like udev, upower, devd or some such in
charge of assigning filesystem permissions to USB device nodes - should get
owned by NUT run-time user?
Alternatively, try adding `user=root` line to
Cheers,
Looking at the `vendorid=0x10af` -- the usbhid-ups subdriver `belkin-hid`
has the best chance here (being the only one to mention it).
The `productid=0x0002` is indeed not mentioned in `drivers/belkin-hid.c`
so probably nobody encountered it before and/or tested a hotfix to PR it
Hello Jeff,
`upsstats` by itself only relays and renders the information provided by
a NUT data server (upsd) and the NUT driver for the device. So you can
revise the specific reported values with e.g. `upsc` command-line client to
be sure.
What I think happens here is that the driver uses a
Cheers all,
you may have seen related preparatory news on the NUT website or in the
README changes, but now the next step is official:
The fine folks at DigitalOcean approved FOSS sponsoring credits to
re-host the custom-built multi-platform non-regression NUT CI farm, which
builds several
Thanks again,
Great to see confirmations of more and more things working!
> I wonder what's the fastest method to test the function (previously I
setup the ups and unplug the utility from the ups for testing).
> is "upsrw driver.flag.allow_killpower=1" then "upscmd driver.killpower"
the
ver author can address the
> nits (forwarding now...)
>
> Jim
>
> On Wed, Nov 22, 2023, 15:05 d tbsky wrote:
>
>> Jim Klimov via Nut-upsuser
>> >
>> > Got an update for APC Modbus users: a new PR is waiting for real-life
>> testing for settable vari
Great! Thanks for the info, and hope the driver author can address the nits
(forwarding now...)
Jim
On Wed, Nov 22, 2023, 15:05 d tbsky wrote:
> Jim Klimov via Nut-upsuser
> >
> > Got an update for APC Modbus users: a new PR is waiting for real-life
> testing for
Got an update for APC Modbus users: a new PR is waiting for real-life
testing for settable variables and instant commands support.
https://github.com/networkupstools/nut/pull/2184
As before, a custom build of libmodbus may be needed for USB support
(detailed in the earlier PR), but Serial and
NOTE for packagers (and other builders of NUT release tarball):
Got an ERRATA to NUT v2.8.1:
*
https://github.com/networkupstools/nut/pull/2155/commits/2842201db26468a1eb1bf579e8b2fbf7538c5076
Probably should have a short cycle before a NUT v2.8.2 with smaller scope
than originally anticipated
Cheers all,
Issue https://github.com/networkupstools/nut/issues/723 was brought up
recently, and I've re-verified it with the current codebase that it still
happens.
The crux of it is that if upsd can LISTEN to some but not all addresses,
it aborts because "no listening interface available"
...it was almost midnight, Cinderella became a pumpkin, and NUT was
released!..
Trick or treat?!
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Hello again :)
> Aren't the drivers daemonized and isn't it the drivers that kill power
already?
Historically, a mixed bag: they are daemonized while monitoring, then they
exit (or are killed) as part of shutdown, and then a late-shutdown script
(historically a patch to rc.halt or similar
Hello all,
Thanks to everyone who chimed in with tests, ideas and even freshly
confirmed regressions introduced by NUT v2.8.0 release compared to v2.7.4
(yes, there were after all a few eggs broken to make that omelette, with
all the code clean-up that went into it), so now I feel more
OTOH: I wonder whether, when it says "Claimed interface 2 successfully" it
got the right number of the correct (HID) one of many interfaces you likely
have there?.. :\
Jim
On Mon, Oct 30, 2023, 00:04 Kelly Byrd wrote:
>
>
> Apologies for the long post. I'm trying to include what I hope are
Would this help?
https://github.com/networkupstools/nut/pull/2136
Jim
On Sun, Oct 29, 2023 at 5:04 PM Vojtěch Hurčík wrote:
> Thanks for the reply, it's only reported once per spawned process and what
> you say makes perfect sense in this light. A configuration toggle or
> environment
Thanks for your concern.
Technically, it is not about just systemd - other systems where launched
processes that have ways to interact with some OS framework (like SMF,
upstart, Windows services, docker/kubernetes, whatever) *and* such
framework offers ways for services to inform they have
Is the battery old? PbAc ones usually last for 2-3 years and then degrade.
Should be a field-replaceable part.
Some 20 years ago I had an APC BackUPS become a glorified power strip every
few years, so when the wall power disappeared - load went down immediately.
It was also beeping about battery
Check it out now,
my NUT project braza!..
https://github.com/networkupstools/nut/pull/2133
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
Jim
On Fri, Oct 27, 2023 at 8:07 PM Jim Klimov wrote:
> Hi, this does sound like a
Hello, fellow NUTs!
This October proved to be a rather productive month, with several
developments wrapped up, as well as some issues with master codebase
behavior created, reported, fixed and tested :)
While we were not part of some official Hacktoberfest this year, it
pretty much felt like
Hi, this does sound like a useful idea - although for the principle of
least surprise and for variation in deployments, I'd rather have it as a
(non-default state of a) configuration toggle that can be set via
`upsmon.conf`: whether this particular client exits after processing FSD or
not. The
Hello fellow NUTs :)
It is my great pleasure to get a bit of sunshine from other people's
work, and announce that the initial pull request for `apc_modbus` NUT
driver has recently been merged to the main NUT codebase, so it would be
part of an eventual 2.8.1 release. Great thanks go to Axel
Glad it worked out!
> I have not made ANY changes to hosts.conf in my server.
So was this in the end a wrong assumption on your side, or was some error
in the file shipped by packaging (or even NUT upstream sources)?
Jim
On Wed, Oct 11, 2023 at 5:25 AM S K wrote:
> Can close the thread! Had
Well... one troubleshooting idea is to use a sniffer (ngrep, tcpdump, etc.)
to see the dialogue between the web server and upsd data server (
192.168.0.20:3493), to check if anything looks fishy there. Maybe some
firewalls, SELinux after an update, etc. tempered up and there is no
network chatter
Thanks, updated. Should get published soon.
Jim
On Tue, Oct 3, 2023 at 3:05 AM Raymond Burkholder
wrote:
> Hello,
>
> On the page https://networkupstools.org/projects.html, I didn't see a
> general purpose Nut to MQTT client.
>
> I've written one in C++. Source can be found at:
>
Kinda forgot about this aspect, thanks for reminding.
More technical and historical detail here:
https://github.com/networkupstools/nut/issues/630 ... referring to one's
own earlier post - how typical of internet these days! ;)
Jim
On Thu, Sep 21, 2023, 16:17 Eyal Lebedinsky wrote:
>
> On
Hello all,
Over the past years there have been several cases where I wished we could
specify an USB HID subdriver as easily as a subdriver/protocol combo in
nutdrv_qx or blazer drivers, or a MIB in snmp-ups driver. But never got
around to implementing that (nor convinced somebody else to do
One tool for one job :)
You can have another protocol client with GUI. NUT includes a python (qt5
or gtk) set of UI clients.
On Thu, Sep 14, 2023, 17:06 Alessandro Mandelli
wrote:
> It works, but I got an allergy for CLI
>
>
>
> PS C:\Program Files (x86)\NUT\bin> .\upsc.exe UPS
>
> device.mfr:
Ah, I see. My take is that using or adapting something that exists is
easier than starting from scratch - but to each their own. Surely you'll
learn a lot :)
Still, just to clarify: after the NUT v2.8.0 release I began a slow revival
of old NUT for Windows effort (abandoned a decade ago at
So, do you plan to write some new program for that UPS instead of trying to
use NUT? (Note there are also regular Windows builds on CI - with some
caveats so far).
I'm commuting now so can't find links easily, but can suggest you to peruse
the issue/PR tracker, there's a discussion about an SMS
Seems like recent work on nutdrv_qx subdriver armac (merged to master last
month) could handle it, or some older QX drivers like richcomm if it is a
different brew of a loosely similar product.
Try following
Thanks!
So, comparing this with the January report -- there are no substantial
changes in device discovery process and the collected info.
However, the 10K seems to actually report most of the data which we have
to "guesstimate" in other cases.
Hoping somebody else with QX devices would
Hello,
I think this should be possible, probably with dummy-ups or clone*
drivers and respective override.* definitions in the "secondary drivers"
So if something does not work here, I'm ready to consider it a bug. Can
you post samples of config and logs (are there any errors?)
One thing
I don't think they have variables attached (maybe some for known verdicts
after a test). The tests and other available ops should be among `upscmd
-l`.
Jim
On Mon, Sep 4, 2023, 11:12 Łukasz Michalski via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Hi,
>
> I have Eaton 3S 700
eters for initiating the
> shutdown, one can decide something like:
>
> - VMware will shutdown at 20% battery left OR 15min of runtime left
> - NAS will shutdown at 10% ou 8min left
>
> Another approach is to attempt to define a way to sync secondaries… but
> that’s much more co
left
> - NAS will shutdown at 10% ou 8min left
>
> Another approach is to attempt to define a way to sync secondaries… but
> that’s much more complex.
>
> Arnaldo.
>
> On Aug 6, 2023, at 12:39 PM, Jim Klimov via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wr
Hello all again,
While looking at https://github.com/networkupstools/nut/issues/2014 I
understood that I am
not sure if currently NUT has a standard way of triggering a shutdown based
on remaining charge
or runtime, if a device/driver lacks a `battery.charge.low` setting but has
readings for
gs that this happens.
Jim Klimov
On Sat, Aug 5, 2023 at 2:24 PM Greg Troxel wrote:
> Jim Klimov via Nut-upsuser writes:
>
> > I've recently found that at least on my test box the `LISTEN *` line
> had
> > only set up an IPv4 `0.0.0.0` listener but not an IPv6 `::0` listener
Cheers all,
TL;DR version:
I've recently found that at least on my test box the `LISTEN *` line had
only set up an IPv4 `0.0.0.0` listener but not an IPv6 `::0` listener for
`upsd`. In fact, at least on a "dual-stack" system, it seems impossible to
bind to both - so depending on binding order
Hello all,
A recent issue discussion pointed me to an Android app called
"apcupsd-monitor", which is in fact *also* capable of NUT and Eaton IPM
(via XML/HTTP?) protocols, and looks quite neat for a mobile dashboard:
* https://github.com/networkupstools/nut/wiki/Android-clients
*
I think the client should be able to do that with `upssched` as long as the
`upsmon` calls it to trigger the events. Thinking of it, the common
use-case is indeed time (e.g. 5 minutes after on-battery, certain systems
begin their shutdown), or the primary upsmon telling others to FSD ASAP.
Maybe
Hello, interesting to hear. What version of NUT, what way of installation
on Windows, what sort of UPS (USB or some other)?
Asking because this info is lacking and currently there are a few variants
to consider:
* an MSI package based on NUT v2.6.5 (last released about 9 years ago as
"2.6.5-6"),
Yes, the bug was about conversion of `upsdebugx()` and friends to macros,
so actual methods (and their parameter evaluations) only waste CPU cycles
when the verbosity level is high enough. Otherwise lots of logic was
executed to prepare method arguments only for it to bail out in the first
line.
Ah, I thought you missed in my earlier reply the part about a bug with
debug printouts in 2.8.0 (fixed on master since), did not comment on that
when you replied with quoting... So, for now options are to bump debugging
to 3+ or to build your own in one of many ways possible :\
On Wed, Jul 5,
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
Hello, thanks for the report and trying to wrap my head around it.
On a side note, it seems you've reported the same(?) UPS a couple of
decades ago? ;)
https://networkupstools.org/networkupstools-master.github.io/ddl/Exide/NetUPS_SE_PRC2400a.html
=>
Cheers,
Trying to wrap my head around an issue discussed in
https://github.com/networkupstools/nut/issues/1925
The gist of it is that despite the usbhid-ups driver running as `root`
and seeing most of the regular run-time info, in the initial device search
it fails to find basic matching
Unfortunately it is vague, at least on the NUT side, since it really
depends on capabilities of particular hardware (and then on who coded what
in NUT drivers and mapping tables). Often this level of precision is not
available or manageable externally at all, NUT or not (e.g. WebUI of an UPS
might
Not fully true about example configs in docs: man pages for CGI bits have
some :)
https://github.com/networkupstools/nut/blob/master/docs/man/upsset.conf.txt
https://github.com/networkupstools/nut/blob/master/docs/man/upsstats.cgi.txt
Thanks for the feedback.
Just the bit about "when provided by Debian" concerns me - we have a
slow-ish cadence of releases, and then distros take another year to ship
them :\
You might be reasonably served by a custom build (in-place or even
package). YMMV...
Jim
On Tue, Jun 13, 2023, 18:38
After launching the command several times, with debug (posted by new code
in a new branch for the investigation) confirming that the same daemon
handles operations from the new client instances, its strace now has
numerous FDs to report after select() - so I guess it is a problem of
detecting an
So, got some good news: I hear(*) I managed to reproduce the problem with
current NUT master and an adapted copy of your posted configs and script :D
Experimental debugging now sounds possible.
(*) PC under the desk wails with all its cooling fans as soon as I started
the client which spawned a
1 - 100 of 285 matches
Mail list logo
