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` lis
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 I
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
* https://play.go
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 t
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.
I
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, 2023
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
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
=>
https://github.com/networkupstools/nut-ddl/blob/
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 info
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
https://github.com/networkupstools/nut/blob/master/docs/man/hos
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 Kar
So... determining that FD is to be reaped proved hard. Internet lore
suggests fcntl() and poll() on the FD, but it just seems valid to them. The
errno is also usually not raised (once I saw a "111: Connection refused"
though).
So the best dumb idea so far is to bail out if we spent the whole loop (
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 ex
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 da
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
FWIW, I wonder if this is a fallout of PR #1274 :
https://github.com/networkupstools/nut/pull/1274/files
and specifically
https://github.com/networkupstools/nut/commit/550064930e369fb3a322c3b288b4acf53532
which added a `sock_read()` loop continuation effectively if `pconf_char()`
returned 0.
J
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 events), around here:
https://github.com/networkupstools/nut/blob/v2.8.0/clients
Hello,
Thank you for the report and I don't recall any similar issues.
Unfortunately, upssched did not have any "native" enablement of debug
verbosity in 2.8.0 and older releases (some added with
https://github.com/networkupstools/nut/pull/1864 recently), so maybe the
best way to get more inf
Looking at sources, it seems your logging tech (throttling?) ate half of
the message which is there since at least 2005:
upslogx(LOG_ERR, "Unable to use old-style MONITOR
line without a username");
upslogx(LOG_ERR, "Convert it and add a username to
u
As a wild guess, your `upsd.conf` tells it to listen on `127.0.0.1`
explicitly, which may be why it refuses to listen on wildcard `0.0.0.0`.
However the clients connect to `localhost`.
How is the system name resolution set up (check `/etc/hosts` as a starting
point) - can `localhost` there mean IP
I think you have just the libraries - also you'd need a *-dev package for
headers. The docs/config-prereqs.txt has the dependencies in more detail.
In quick practice, --with-all=auto can help better if you don't monitor a
netxml device ;)
HTH Jim
On Mon, May 22, 2023, 15:24 gene heskett wrote:
Makes sense, and a PR is a way to solicit feedback :)
I'd document this for ups.conf (man page and examples), including a note
that for devices which do provide a healthy LB these values may be set to 0
safely. Wondering if non-zero defaults should be there anyway. @Community,
WDYT?
Also, this cr
Cheers,
Is anyone online well versed in APC device support, to help out with
https://github.com/networkupstools/nut/issues/1941 ?
TIA,
Jim
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman
Also, if you figure out this rebuilding bit for OpenWRT, a how-to on NUT
github wiki would be welcome (and may help you in the future) :)
Jim
On Mon, May 8, 2023, 19:19 Jim Klimov wrote:
> For clarity, `upsd` is the networked data server for local or remote
> clients like `upsmon` or `upsc`. It
For clarity, `upsd` is the networked data server for local or remote
clients like `upsmon` or `upsc`. It talks to locally running NUT driver(s)
which talk to actual devices with their media and protocols. It is the
driver (like `usbhid-ups`) that would be annoyed by hardware reconnections.
That sai
I'm mostly not online for a few more days, so can't check directly.
The general answers to the two questions would be:
1) checking if it is there:
* revise if it is mentioned in the NEWS file (in sources - release tarball
or on github);
* check issues on github;
* search/grep for 3024 in current/
I think 3024 was added after NUT 2.7.4 release.
On Thu, May 4, 2023, 18:20 Feliciano Chavez via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Dears,
>
> I'm trying to connect this new version of the AVR700U to nut - 2.7.4-27
> running over OpenWrt 22.03.5, installed from the stable
ups.load:8 is 8% right? just the RPi or more serious load? At lower values,
the gauge might not be precise, maybe...
Wondering why the shell froze - could be systemd waiting for startup to
complete (driver and other daemonware signalling it is forked and ready),
which might take time. The `journal
That's odd - a name like this is not default I think, so either you passed
it to configure script options, or in-place config mode deduced it from
packaging remnants?..
Either way, better than running as root or nobody, so useradd (maybe also
groupadd) are your friends here :)
Ideally, NUT driver
For the final part after the build, I'd do this to make sure systemd units
get defined, activated and started:
:; make -j 4 all && make -j 4 check && \
{ sudo systemctl stop nut-monitor nut-server || true ; } && \
{ sudo systemctl stop nut-driver.service || true ; } && \
{ sudo systemctl
Thanks, I'll post an update :)
Jim
On Mon, Apr 24, 2023 at 10:37 PM Phil Stracchino via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> The good news:
> While gathering information for this post, I solved the ORIGINAL problem
> I was going to post about, which was figuring out how to
You mentioned the RPi runs a buster-based OS?
I suppose the simplest way is you can forgo the init-scripts and retain
just the systemd services (as listed in the article - including the
nut-driver-enumerator which would create nut-driver@myups.service based in
the ups.conf section).
Jim
On Mon,
"I'd thought you'd never ask" (C)
Can you give this walkthrough a shot?
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
Jim
On Mon, Apr 24, 2023 at 8:00 PM gene heskett wrote:
> On 4/24/23 13:12, Greg Troxel wrote:
> > gene
As a follow-up, that R&D led to several other issues and PRs, now mostly
merged and summarized in
https://github.com/networkupstools/nut/issues/1781#issuecomment-1519824607
(with a few points still awaiting completion).
They added new features to NUT master branch, including:
* drivers/upsdrvquery
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.
This normally depends on two things: vendor MIB allowing such control over
SNMP at all (e.g. "write this number to this OID to set the load-delay
timer for this outlet"), and someone having added and tested such mapping
to NUT common data-point naming (in a relevant *-mib.c subdriver).
So here NUT
Specify the ups.conf data points including the IP address/hostname of the
UPS as "port", the community (for SNMPv1/2) or real auth (v3), and
optionally the MIB you prefer (by default the driver auto-picks known
vendor extended MIBs until it tries the IETF standard MIB as the final
fallback).
Make
On top of what Greg said, see if your udev.rules file provided by the NUT
package includes the vendorid:productid for your device. The
`ups.status:OB` (unless you're testing and it is really on battery) seems
like a short read of USB reports. Boosted driver debug may confirm it, like
`expected 900-
Isn't "nut" package there an umbrella/meta-package (in terms of other
distros) to pull together the likely suspects in one command?
Not at a computer now, but I think Debian and OpenIndiana packages were
grouped this way. Likely all packages with daemons would depend on a
"nut-common" package then
Glad to hear it!
Jim
On Wed, Mar 29, 2023 at 3:06 PM wrote:
> Hi Jim,
>
> I’m using on Kali Linux.
>
> I’m not using a custom version and finally found the issue which was a
> hidden character staying in the ups.conf file.
>
> I rebuilt the file and everything worked out.
>
>
>
> Issue closed an
Which OS is that? With Linux+systemd, I'd expect systemd to start the
drivers (hence blocking the port) and keep logs in the systemd journal (if
your packaging includes nut-driver-enumerator, you may see them with
`journalctl -lu nut-driver@myups3`; for older systems just `journalctl -lu
nut-driver
Also, just in case - are you in a virtualized environment? Is there
(intentional or not) USB pass-through to the UPSes? My hint is, we had
cases where a host or guest grabbed the device but it was not apparent from
the part of system running NUT.
Jim
On Fri, Mar 24, 2023, 23:23 Jim Klimov wrote
Sounds like some other program is holding the port. Have you stopped other
NUT drivers for the device (e.g. via auto-resuscitating services) before
starting this one? Does udev, ugen or similar facility have the
configuration to hand off this device to NUT run-time user? (BTW, if you
are now testin
The "unknown" fields mean the driver did not get that piece of information
from libusb. In case of Manufacturer/Product which are unknown in the later
post, but known in the first, I suppose you had another driver running, or
the kernel still owned it (udev misbehavior, not handing it off after
rec
Thanks to Roger Price for starting and maintaining the book, now officially
at version 3.0:
*
https://github.com/networkupstools/ConfigExamples/releases/download/book-3.0-20230319-nut-2.8.0/ConfigExamples.pdf
Have a fun read!
Jim Klimov
___
Nut-upsuser m
Hello, and thanks for the details.
The device matcher goes through given configuration "clues" until something
does not match (so with few enough clues it could not discern several
identical devices causing a undefined behavior (for more info peruse
https://github.com/networkupstools/nut/issues?q=
> Do you think there could be some merit in either embellishing dummy-ups
or deriving a new driver from it that is sanctioned as a 'file-based'
interface for NUT?
I'd say one problem would be relative inefficiency and overheads: you have
one process talking to the device to extract data, save it
Is that with both UPSes on same machine?
A quick guess would be that insufficient data points to identify the device
are configured (vendorid, productid, serial...) in ups.conf, so both
drivers connect to the first match. I'd expect them to conflict and one
would die or both loop reconnecting, if
Thanks to everybody who has already responded, you are great! :)
As usual, developers are also called up to volunteer, we have a few PRs to
make sense of, test/fix and deem worthy of a merge, as well as that bounty
recently revived for supporting data points in an UPS (see recent ML
history)...
J
Hello all,
For decades, the NUT project ran without any formal entity or a "money
purse" of its own. This proved to be a somewhat limiting factor, since paid
services like DNS have to be covered by maintainers (as in ancient times,
when city celebrations were paid by randomly elected officials p
Hello,
Yes, "pollonly" is a driver option for certain devices (and relevant to
just some drivers).
Disconnects are probably relevant, at least to loss of connection (and
staying that way, with less agressive retries in NUT v2.7.4 and before).
There is a logged issue that "pollonly" mode might hav
Hello,
On one hand, sorry to hear that higher polling frequency in upsmon did not
help. On another, question is if the driver gets the info (online state and
its changes) from device quickly enough.
Initially I meant for you to also try if the "pollonly" flag (in each
device section of ups.conf f
Hello,
Also note that NUT project does not currently issue packages, and I have
a hard time guessing what distro might ship a "driver.version:
DSM7-1-1-42930-workplus-version2-repack-42930-220712". Ask them what NUT
version (release or snapshot) they use, and if they would consider shipping
a ne
Hello,
Looking at "udevadm[666]: systemd-udev-settle.service is deprecated. Please
fix nut-driver@ups.service, multipathd.service not to pull it in" above and
https://github.com/openzfs/zfs/issues/10891#issuecomment-749479690 quote
about the deprecation in particular, I wonder if in fact your OS t
Hello all,
Did anyone pick up this "growth opportunity" to modernize a Qx subdriver
and protocol docs library, with vendor cooperation, and possibly get paid
and/or an UPS to test against in the process?
Or would someone step up to do so, please? It would be folly and
unhealthy of the NUT com
Cheers,
There were some discussions in the recent past about confusing NUT
behavior and messages when a system wakes up from sleep or hibernation,
which could be triggered by NUT itself as a SHUTDOWNCMD (or not).
I've tried to generalize the ideas about the problem and possible
solution(s) at
Hello all,
I've long felt that I am reciting tips about building from git source a
bit too often in the issue discussions over the past couple of years, and
automated some of that area during the time to make it simple to type, so
finally posted a Wiki article that I hope to refer to in such sit
batt.volt.low);
would be ( 100 * (13.5 - 10.4) / (15.0 - 10.4) ) = 67.39...
Close enough to explain the value seen, at least.
Jim
On Tue, Jan 17, 2023 at 10:04 AM d tbsky wrote:
> Jim Klimov via Nut-upsuser
> >
> > Cheers,
> >
> > One PR waiting to get into 2.8.1
Cheers,
One PR waiting to get into 2.8.1 release timeframe is
https://github.com/networkupstools/nut/pull/1652 stemming from issue
https://github.com/networkupstools/nut/issues/1279
The gist of it is that "battery.voltage" and "battery.charge" were not
always reported correctly with nutdrv-qx
FWIW, https://github.com/networkupstools/nut/pull/1709 (when merged) should
over time make custom rebuilds to replace standard packages (or older
custom builds) easier by tracking CONFIG_FLAGS involved in the existing
binary build.
Jim
On Sun, Jan 15, 2023 at 11:49 AM Jim Klimov wrote:
> What
What Charles said ;)
Generally (for any random OS) it is about a couple of things:
* Getting build environment/prerequisites set up as needed:
- reading NUT docs/config-prereqs.txt can go a long way for many OSes
that CI regularly tests (or does not to regularly, but were touched upon
once since
;
>>>> model = "CP685AVR-G"
>>>> vendorid = "0764"
>>>> product = "CP.*"
>>>> bus = 003
>>>> device = 001
>>>>
>>>> Note that for older NUT bui
>> libusb-1.0 API this should be the non-zero hardware-related port number (if
>> supported by HW/OS/drivers) by default (or iteration counter if OS does not
>> tell).
>>
>> On Sat, Jan 14, 2023 at 8:16 PM Bruce Pleat wrote:
>>
>>> Thank you both for answ
>
> I am not in position to change versions now - I am using whatever is
> installed by Bullseye/Raspbian. (I wouldn't know how to ask the package
> version be updated?)
>
> If I unplug them and switch the order I plug them in (regardless of USB
> slot?), it impacts which Cyber P
Actually in merged PRs of recent weeks there can be several suitable fixes:
1) support for common USB matching parameters in more drivers (though
usbhid-ups has long had it);
2) nut-scanner should provide more of these parameters in generated config
sections, in particular "device" port numbers;
Cheers,
At least a few things that DO NOT seem right upon quick reading are:
* upsmon.conf:
RUN_AS_USER root
Should not normally be required: when started as root, upsmon splits into
unprivileged process for most of the work and leaves the shutdown handler
running as root; with this setting you
As the man pages say, `pollinterval` is about primarily `ups.status`.
Other values may be scanned as rarely as `pollfreq` in drivers that support
it (hopefully named consistently). Certain drivers or their options allow
for interrupt-based activity vs. "pollonly" mechanism, which has its
upsides (
Thanks,
A "-q" (or an envvar to same effect) is another way to skin the cat, as
discussed in that ticket and now followed-up by
https://github.com/networkupstools/nut/issues/1789
It still leaves open the question of whether default runs of NUT programs
- especially as services or shutdown hoo
Hello all,
During discussion of https://github.com/networkupstools/nut/issues/1782
me and Greg uncovered a diametral difference of opinion about the verbosity
of NUT programs in general, and of `upsmon -K` (checking for POWERDOWNFLAG
during shutdown integration) in particular.
To me as a sysa
I would guess configuration of `pollonly` vs. interrupts (lack of pollonly)
can play a difference - at least worth trying. Different HW (mis-)behaves
differently with these option, no "one to rule them all".
Jim
On Sat, Jan 7, 2023, 20:44 jack Bamford via Nut-upsuser <
nut-upsuser@alioth-lists.d
> So I'll have a look at this file being removed on upsd startup, or in our
rc.d scripts for now.
Note: it *is* removed upon `upsmon` startup (any successful one, except for
sending signals `upsmon -c CMD` or querying this file `upsmon -K`).
Also checked that this is a rare path not hardcoded into
https://github.com/networkupstools/nut/pull/1762 (and maybe some of other
recent PRs) updated quite a bit here and there, including a configure-time
option for default POWERDOWNFLAG value (using legacy default still).
Distros now have easier time to put it into a tmpfs of their choice that
they kn
Hello,
Good question - I hoped to deal them out twice a year or so, but it
(toxically, in hindsight) stumbled on trying to adddress a few bugs
reported in 2.8.0 to deliver fixes as 2.8.1 :\
I've dealt with projects that port stuff to a release/stable branch, and
at least for a small team like
Hello all,
During holiday revision of issues (hoping to tie up loose ends and get to
NUT v2.8.1 soonish), an old https://github.com/networkupstools/nut/issues/50
ticket came to my attention - that some years ago "we" (as NUT community)
wanted to create an unified driver for devices with a Modbus
On Tue, Jan 3, 2023 at 8:18 AM Gennadiy Poryev via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> May be, I don't know. My UPS doesn't autopower on after charging its
> batteries full.
>
> Anyway how do I test it? There has to be some specific way of shutting
> down to see if that wor
roblem, but otherwise everything seems
correct and predictable ;)
Hope this helps,
Jim Klimov
On Thu, Dec 29, 2022 at 9:11 PM Roger Price wrote:
> On Thu, 29 Dec 2022, Jim Klimov via Nut-upsuser wrote:
>
> > > Ah, dropping the ""s seems to have resolved it.
> >
>
With some APC rack SmartUPSes of early 2000's, as well as some larger Eaton
devices, I remember them auto-powering on the load only after they charge
"enough" (configurable in Eatons at least) to run for say 10 minutes - so
they can tell the load to power off and hold it up long enough to guarantee
I wonder if you refer to
https://nut-upsuser.alioth.debian.narkive.com/Fj636tRZ/support-of-shutdown-return-on-a-apc-back-ups-cs-500
discussion from a decade ago...
Essentially, with the command you tell the UPS to cut power in X seconds
from now (some may not support it at all, some may have effec
Let's hope it will prove to be better than the last... several.
Season's greetings and best regards,
Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Hello, please try installing (perhaps custom building) a NUT 2.8.0 or newer
(master) - Salicru contributed subdrivers for some of their devices.
Jim
On Fri, Dec 30, 2022, 16:26 Håkon Alstadheim via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Hi all and merry christmas! I'm new t
> Ah, dropping the ""s seems to have resolved it.
Interesting, which of the two places got it wrong? Sounds like a bug... I
think parser should ignore quotes (not take them as content - just treat
the insides as one token) unless escaped, in both config file contexts.
Gotta revise if NIT checks f
Heads-up note: Recent PR https://github.com/networkupstools/nut/pull/1742
introduced an option for custom NUT builds to report "unmapped.*" values
discovered by a subdriver generation script (usbhid-ups, snmp-ups) which
were previously unconditionally hidden by `#if 0` clauses. They are still
not c
OTOH, is the `upsd.users` file set up right?
* permissions for only nut OS account to read it
* upsmon primary/secondary role specified for that nut user section
* no typos in password :)
Jim
On Thu, Dec 29, 2022, 01:04 Orion Poplawski via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrot
Well, NUT prides itself on an ability to build and run roughly on anything
built this millennium ... or end of last one - give or take, wherever older
versions worked, there are not many reasons for new ones to not work at
least to same extent as they did.
But it feels wonderful to (tinker a bit a
Thanks, hit that snag too - it was fixed in my branch `if (MAYBEMACRO + 0 <
SOMEVAL)` trick.
For core files, Solaris has a nifty `pstack` others lack.
Or you can call `gdb upsmon`, enter `run`, and if it coredumps - `bt` for
backtrace (annotated in debug builds). There were some more complex ways
One thing that popped up in this quest was that Solaris 8 libc does not
take kindly to code similar to:
printf("%s", NULL);
...which ends up dereferencing that NULL to check strlen() - and I suppose
can happen when debug messages are logged with little regard to arguments
(newer libc's are sm
Prospective fixes posted to https://github.com/networkupstools/nut/pull/1738
- hoping the multi-platform CI would survive these changes elsewhere.
Probably a few follow-up fixes will land over time...
You can try to check out and build this branch :
https://github.com/jimklimov/nut/tree/sol8
Defa
Cheers, trying to recreate this issue over the holidays to the best extent
I currently can (with an x86 VM) - that went well (problems reproduced).
Tracking some detailed discussion in
https://github.com/networkupstools/nut/issues/1736
Regarding the `--without-nut-scanner` (named so in the end) o
Do you mean presence of wall power? That would be `upsc` momentarily asking
for `ups.status`. For its quality - `input.voltage` etc. assuming your UPS
reports it.
For history - some monitoring tool (MRTG etc.) doing the same continuously.
Maybe `upslog` would do.
Jim
On Mon, Dec 19, 2022, 23:49
Adding to Greg's good questions, is the UPS (battery) new or old? Perhaps
the PbAc worked over ~3 years and indeed the UPS became a glorified power
strip? I had some BackUPSes do that every couple of years a decade to two
ago...
Hope this helps,
Jim Klimov
On Mon, Dec 19, 2022, 14:18 Greg Troxel
Thanks, puzzling... as another datapoint, would NUT's `make check-NIT`
behave reasonably? It is a set of (hopefully portable, not just bash)
scripts to set up and run upsd vs upsc locally. Would at least that work?..
Also, would the older NUT 2.7.4 release fare better? It is pre-refactoring
that h
Maybe also try strace, truss and the likes to see what syscalls it makes?
e.g. falls on read/select?..
Jim
On Sun, Dec 18, 2022, 23:04 vom513 via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Debug doesn’t seem to say much:
>
> [root@ss20 ~]# LD_LIBRARY_PATH=/usr/local/ups/lib
> /u
Don't have a SPARC machine anymore, but it is regularly tested on illumos
(which is ages newer than Sol8)... wondering if I can get an x86 vm running
with it...
In the meanwhile, add some `-D` options to the launched program so it is
more verbose. Is that other NUT (upsd) listening not on localhos
Haven't used WinNUT(-Client), that is a community project and not part of
NUT itself. Hope someone else here had experience with it to answer
specific questions.
However, since recently NUT for Windows is a thing again (though packaging
is not finished) so you can try tarballs built by Appveyor CI
FWIW, this and other recent discussions led to a few PRs and investigative
issues about paths and PIDs and signals - so here's some reading for your
enjoyment:
* https://github.com/networkupstools/nut/pull/1724
* https://github.com/networkupstools/nut/issues/1721
* https://github.com/networkupstool
For the sake of cross-referencing, posted an issue at
https://github.com/networkupstools/nut/issues/1727
On Thu, Dec 1, 2022 at 7:44 PM Jim Klimov wrote:
> Curious finding up there. I think this is due to `load_upsdconf(0);`
> being at
> https://github.com/networkupstools/nut/blob/master/server/
Curious finding up there. I think this is due to `load_upsdconf(0);` being
at https://github.com/networkupstools/nut/blob/master/server/upsd.c#L1776
being after the initial signal-probing for competitors (or sending a
command to a running daemon), so using built-in PID/STATE paths, and
notably that
The `nut-server` (upsd) should be looking for pipe-files from drivers in
the "STATEPATH" (should be `/run/nut` in your case as the driver got set up
like this now).
The `/var/run is world readable` complaint indicates the `upsd` looks in
`/var/run`rather than `(/var)/run/nut`.
While debugging sta
101 - 200 of 316 matches
Mail list logo
