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.
ue-2450 nut-issue-2450; cd
nut-issue-2450 ; ...` to those instructions).
Thanks in advance,
Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
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
rden off myself (and avoid regular re-merge and rebuild to have both
feature sets in my deployments), and of course to have my contributions
reviewed and stupid (or un-trivially hidden) mistakes weeded out :)
Hope this helps,
Jim Klimov
On Sun, May 19, 2024 at 8:06 PM Kiril Zyapkov
wrote:
e from data mappings - most of these are largely C tables already.
Hope this helps,
Jim Klimov
On Thu, May 16, 2024 at 12:27 AM Kiril Zyapkov via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Hello,
>
> I found out about NUT just days ago while searching for a solut
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 ab
g up to
your MINSUPPLIES for a healthy uptime) and other MONITOR lines with the
zero amount of fed PSUs.
Hope this helps,
Jim Klimov
On Thu, May 2, 2024 at 9:22 AM Alexander Hofmann via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Dear all,
>
> I might have a somewha
rvice name string to
> port".
>
> On Mon, Apr 29, 2024 at 6:32 AM Greg Troxel via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
>> Jim Klimov writes:
>>
>> > Just to clarify: using a different port *is* possible since forever,
>>
relays on the
other), or attempts to avoid conflicts with uncooperative software. Can't
think of much more quickly :)
Hope this helps,
Jim Klimov
On Mon, Apr 29, 2024 at 2:31 PM Greg Troxel via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Jim Klimov via Nut-upsdev writes
s through the naming database (resolve via
typically /etc/services on POSIX systems) if it is a non-numeric string,
similar to how we resolve host names into IP address numbers?
What would the community say, is any of this worth spending time on?
Would anyone volunteer to roll up the sleeves for
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 n
(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 wrote:
&
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 ma
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
>
was released but slipped away with an earlier commit.
Other artifacts should follow shortly.
Jim Klimov
as the field nurse
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
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
) at the right time :)
Jim Klimov
On Mon, Mar 25, 2024 at 7:41 AM Juan Carlos Fischer <
juancarlos.fisc...@gmail.com> wrote:
> Hello Jim!
> First of all, allow me to thank you for your time and invaluable help.
> Exactly arm v7l are 32 bit. I will conduct several tests and keep you
ps://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
- or wait for eventual release and some time later packaging of NUT 2.8.2...
Hope this helps,
Jim Klimov
On Mon, Mar 25, 2024 at 7:41 AM Juan Carlos Fischer <
juancarlos.fisc
000)
> /lib/ld-linux-aarch64.so.1 (0x007f904df000)
> libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x007f9021)
> libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0
> (0x007f901e)
>
> Best regards,
> -jcf
>
>
> On Wed, Mar 20, 2024 at
ertPSA
> ups.productid: 0001
> ups.serial:
> ups.status: OL CHRG
> ups.vendorid: 10af
>
> Regards,
>
> Juan Carlos
>
> On Wed, Mar 20, 2024 at 4:22 PM Jim Klimov
> wrote:
>
>> Hello,
>>
>> For clarity: what changed with the move from NUT v2.7.4 to 2.
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
lso looks like a fun date to
push current code out for a newer public baseline and collect feedback.
WDYT? Is there any known severe breakage on master?
Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-list
y, at least it would get built
along with `upsmon`.
Hope this helps,
Jim Klimov
On Sun, Mar 3, 2024 at 5:32 PM Dan Grostick via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> PI OS - Debian12 - Raspberry PI 5 NUT 2.8.1
>
> I'm building from source just downloaded
to Git, this ID should be known in NUT v2.8.0 or newer (so the
rest is about OS integration for this bit):
$ git blame v2.8.0 scripts/upower/95-upower-hid.hwdb | grep usb:v0764p0601
8b72ac9fc2 (Benjamin Berg2022-03-28 17:19:41 +0200 103) usb:v0764p0601*
Hope this helps,
Jim Klimov
On Wed, Feb
rt
routine if nobody is around.
Hope this helps,
Jim Klimov
On Thu, Feb 22, 2024 at 12:10 AM Andrei Zmievski via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Hello,
>
> I am a new user of NUT and trying to wrap my ahead around a couple of
> things. I install
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
in libusb1.c (on github), but not in a way that makes it
> obvious how to track down the cause. I suspect some sort of version or
> parameter mismatch somewhere in libusb, but I have no idea how to test for
> that.
>
>
> On Wed, Feb 7, 2024, at 12:57 PM, Jim Klimov wrote:
>
> Hello and welc
on ups.conf contents (start-up) or changes (run-time). Check if you
have `nut-driver@PowervarUPS01.service` (and `...@APCUPS01`) there to fit
this bill? If yes, then to experiment with CLI copies of drivers,
`systemctl stop` such unit(s).
Hope this helps,
Jim Klimov
On Wed, Feb 7, 2024, 14:48 Jason
by confirming that it works or by uncovering more edge cases that are
not well handled, help improve an upcoming NUT v2.8.2 release :)
Hope this helps,
Jim Klimov
On Sat, Jan 20, 2024 at 1:07 PM Stefan Schumacher <
> stefanschumacheratw...@gmail.com> wrote:
>
>> Hello Jim,
&g
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
or a dozen
UPSes, or so we hoped).
Good luck,
Jim
On Fri, Jan 19, 2024 at 8:35 PM Jim Klimov wrote:
> > 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.
>
> Actuall
> 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
n.
>
>
>
> Thanks in advance
>
>
>
> Eddie
>
>
>
> *Von:* Jim Klimov
> *Gesendet:* Donnerstag, 11. Januar 2024 19:14
> *An:* edward.ebay
> *Cc:* Arnaud Quette via Nut-upsuser
> *Betreff:* Re: [Nut-upsuser] Windows NUT Client - Settings description
&
farm,
sponsorship becoming a thing, and a new release getting cut - we're back on
track of getting one at least every year (sure hope for more)!
Thanks to everyone involved,
on behalf of the Network UPS Tools project,
Jim Klimov
___
Nut-upsuser mailing
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,
of this driver and
use-case, your best shot is "built by yourself" anyway, since distributions
are not likely to ship the libmodbus with USB patches added (they are not
merged into upstream code yet).
Hope this helps,
Jim Klimov
On Sun, Dec 10, 2023 at 3:48 PM James Parascand
wrote:
>
he NUT
CGI programs, their permissions and credentials, enabling the web-server to
publish them, etc.?
Hope this helps,
Jim Klimov
On Sat, Dec 9, 2023, 20:11 James Parascand via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> I have installed NUT Server and everything went fi
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
if the device/protocol lacks the
ability on its own.
Hope this helps,
Jim Klimov
Jim
On Thu, Nov 30, 2023 at 12:57 AM Jeff Rickman wrote:
> Hello,
>
> I am using Nut 2.8.0 (2.8.0-7 packages) Debian 'Bookworm' in it's Devuan
> form 'Daedalus'.
>
> When I look at my Eaton (ex-MGE Po
are way more "liked"! ;)
Long story short: when you visit official repos of projects you use and
like, don't hesitate to "star" them - sooner or later it can help them
tangibly!
Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuse
tion in
https://github.com/networkupstools/nut/pull/2184 discussion (also
referenced your replies there). Actually, now I wonder (did not test) how
`upsmon` interacts with `upssched` in case of calibrations, if this is
suppressed or not...
Jim
On Mon, Nov 27, 2023 at 1:50 PM d tbsky wrote:
> Jim K
I believe some fixes were applied to the branch since your report (most
visibly, about battery time settings), are you in position to test how it
behaves now? :)
Thanks in advance,
Jim Klimov
On Wed, Nov 22, 2023 at 3:20 PM Jim Klimov wrote:
> Great! Thanks for the info, and hope the dri
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
and TCP may already be well served
by a distro near you!
Jim
On Sun, Oct 22, 2023, 01:08 Jim Klimov wrote:
> 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
> driv
:\
In the meanwhile, packages of NUT v2.8.1 are encouraged to apply a small
patch per referenced commit.
Jim
On Tue, Oct 31, 2023 at 11:51 PM Jim Klimov wrote:
> ...it was almost midnight, Cinderella became a pumpkin, and NUT was
> released!..
>
> Tr
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
finally told to go down, up
to the sysadmins to make sure this happens after all the heavy services are
safely parked). This is available on master branch now, and should be part
of NUT v2.8.1 release soon.
Hope this helps,
Jim Klimov
On Tue, Oct 31, 2023 at 11:27 AM Magnus Holm
y to
check the recent master branch buildability and behavior... perhaps with a
focus specifically on the changes that landed with the most recent fixes in
the past few days.
Thanks again,
Jim Klimov
On Fri, Oct 27, 2023 at 8:29 PM Jim Klimov wrote:
> Hello, fellow NUTs!
>
>
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
vironment variable also seems like a good idea, but I'm sure I or we can
> also live with the message being reported once per process as it currently
> is... looking forward to the stable release & thanks for everything!
>
> VH
>
> --- Original Message ---
> On Sunday, Octob
e's an error, I want to see nothing") -
and frankly both stances have their merits for different audiences.
Jim Klimov
On Sun, Oct 29, 2023 at 2:45 PM Vojtěch Hurčík via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Hello friends!
>
> With the upco
, and the load did not change too
much).
Hope this helps,
Jim Klimov
On Sat, Oct 28, 2023 at 5:28 PM Gennadiy Poryev via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Hi,
>
> I am sorry for possible offtopic as this question is not quite
> NUT-related but I cannot imagi
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 l
Upgrading_Notes.html#_changes_from_2_8_0_to_2_8_1
- with such release notes publication also being a recent addition.
Jim Klimov
On Mon, Oct 2, 2023 at 5:50 PM Jim Klimov wrote:
> Seconding ... or firsting, considering the recent call to testing hidden
> somewhere in a recent mail post ;) Curre
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
/pull/2063 and
https://github.com/networkupstools/nut/issue/139.
Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
7988], length 28
> 21:55:46.621968 IP 192.168.0.20.3493 > 192.168.0.29.36942: Flags [P.], seq
> 117:146, ack 140, win 509, options [nop,nop,TS val 4073743009 ecr
> 2185139667], length 29
>
>
> On Tuesday, October 10, 2023 at 05:22:28 PM EDT, Jim Klimov <
> jimklimov+...@gmail.com
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
: UPS USB MON V1.4
>
> ups.productid: 1234
>
> ups.serial: unknown
>
> ups.status: OL
>
> ups.vendorid: 0925
>
>
>
>
>
>
>
>
>
> *Da:* Jim Klimov
> *Inviato:* giovedì 14 settembre 2023 15:21
> *A:* Alessandro Mandelli
> *Cc:* Arnaud Quette vi
ad and require fiddling well beyond the capabilities of a standard
> user.
>
> I’d like a native win64 app.
>
> Anyway, thanks for your help
>
>
>
>
>
> *Da:* Jim Klimov
> *Inviato:* giovedì 14 settembre 2023 13:17
> *A:* Alessandro Mandelli
> *Cc:* Arnaud Quette
s.
>
> My prototype is working, at least as proof of concept. I’d just like some
> directions to decode the raw reports.
>
>
>
> Thanks for your help.
>
>
>
>
>
> *Da:* Jim Klimov
> *Inviato:* giovedì 14 settembre 2023 11:48
> *A:* Alessandro Mandelli
> *Cc:
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
ices would chime in then :)
Jim
On Wed, Sep 13, 2023 at 3:26 PM d tbsky wrote:
> jim Klimov
> >
> > Hello all,
> >
> > Had another hard look at the PR for QX device voltage/charge/runtime
> fixes for some broken use-cases (AND hoping to not introduce p
nts=nut-server.service` and
`After=nut-server.service` - so this clone driver would only try to start
when it can actually succeed. Use `systemd daemon-reload` to apply edits.
Hope this helps,
Jim Klimov
On Wed, Sep 13, 2023 at 9:30 AM Steffen Grunewald <
steffen.grunew...@aei.mpg.de&
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
higher values and shutdowns earlier:
>
> override.battery.charge.low
>
> override.battery.runtime.low
>
>
> Won’t it work ?
>
> Best Regards,
> Strahil Nikolov
>
> On Sunday, August 6, 2023, 7:41 PM, Jim Klimov via Nut-upsdev <
> nut-ups...@alioth-lists.deb
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
ne get better versed in yet another programming
ecosystem,
Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
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
complete the Windows codebase integration, someone who
would actually use Windows, UPS and NUT together to find and iron out the
wrinkles. Help is welcome :)
See some more details and further links about this at
https://github.com/networkupstools/nut/wiki/NUT-for-Windows
Hope this helps,
Jim Kli
ed earlier. Otherwise, I
guess, you can find a packaging recipe from distro ("debian" dir is their
turf) and add a patch equivalent to that PR...
Jim
On Wed, Jul 5, 2023, 22:49 Karl Schmidt wrote:
>
>
> On 7/5/23 03:17AM, Jim Klimov wrote:
> > Ah, I thought you missed in my
, 2023, 06:23 Karl Schmidt 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 debu
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
or HWDB override mechanism:
https://www.freedesktop.org/software/systemd/man/hwdb.html
* ...and/or if it conflicts with something due to also-use of some same
SUBSYSTEM (not listed in your snapshot)...
Hope this helps,
Jim Klimov
On Tue, Jul 4, 2023 at 5:08 AM Karl Schmidt wrote:
> Upgraded to D
; (per mge-hid.c logic).
Has anyone please got clues, hints, gut feelings and trench anecdotes to
share? Why could these basics be "invisible" to NUT (as root) while lsusb
and udevadm have no problem reporting them. Apparently a different
APC-oriented daemon also reported the name well.
Th
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
gt; client and the read (from socket) function didn’t return error code, but
> the data length was 0. In the documentation, at least at the time, it
> wasn’t specified directly that it was an error situation. My server code
> looped in a thread hogging CPU. When I modified the code to treat
0, tv_usec=97})
Jim
On Tue, Jun 13, 2023 at 3:41 PM Jim Klimov wrote:
> 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.
>
> (*
722]'
> lrwx-- 1 root root 64 Jun 13 14:36 2 -> /dev/null
> lrwx-- 1 root root 64 Jun 13 14:36 3 -> 'socket:[16427010]'
> lr-x-- 1 root root 64 Jun 13 14:36 4 -> /etc/nut/upssched.conf
> lrwx-- 1 root root 64 Jun 13 14:36 5 -> 'socket:[16426351]'
> lrwx-
FWIW, cross-posted the issue to NUT GitHub tracker:
https://github.com/networkupstools/nut/issues/1964
Jim
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
ue, Jun 13, 2023 at 10:41 AM Jim Klimov wrote:
> Thanks for the interesting puzzle to crunch!
>
> Looking at these few bread-crumbs, I wager an educated guess that this
> loops in `sendcmd()` (where CLI child processes talk to a daemonized copy
> which tracks the timers for ev
1 - 100 of 298 matches
Mail list logo
