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
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.
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:
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
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
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
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
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
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`.
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
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
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
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
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
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:
> >
As a follow-up, that R 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:
*
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
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
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
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
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
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
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
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
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
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
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
> 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
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)...
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
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
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
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
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
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
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)
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
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 release timefra
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
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
model = "CP685AVR-G"
>>>> vendorid = "0764"
>>>> product = "CP.*"
>>>> bus = 003
>>>> device = 001
>>>>
>>>> Note that for older NUT built with libusb-0.1 A
>> 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 a
>
> 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 Power shows u
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
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
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
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 <
> 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
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
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
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
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
m, 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
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
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
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
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>
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
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
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
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
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)
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,
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
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
>
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
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
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
*
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
>
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
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
FWIW, just checked: `git grep nut-client` does not return anything related
to systemd, so that typo gotta be Fedora's invention ;)
In-source there is only nut-common.tmpfiles handling.
Jim
On Wed, Nov 30, 2022 at 8:20 AM Simon Wilson via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
As recently noted in the lists, this was tracked
down to a Fedora 37 packaging bug: https://bugzilla.redhat.com/show_bug.cgi?
id=2127269
I did also recently revise build recipes and in particular use of PIDPATH
(not superficially suffixed with /nut now). Various precedents were messy
and
As recently noted in the lists, this was tracked
down to a Fedora 37 packaging bug: https://bugzilla.redhat.com/show_bug.cgi?
id=2127269
> The nut user does not have write permissions at /run.
Note that /run is linked as /var/run and the nut user DOES have write
permissions there.
These two
Heads-up: A community member had good progress in
https://github.com/networkupstools/nut/issues/1690#issuecomment-1301824123
to properly see an USB UPS.
This effort is becoming more viable over time... :)
Jim
On Sat, Sep 3, 2022, 17:25 Jim Klimov wrote:
> Windoze in da NUT house!
>
> Codebase
On the road now so gotta come back to main question later, but for now -
why 2.8.0-rc3 (not "r3")? There is a newer final release, or current
master... just asking.
Notably, there was a fix in master last week or so that moght help woth
some broken large queries for SNMPv2/v3... No idea if that's
As for startup - yes, it was always the case that drivers and upsd (data
server) start separately even if on the same machine. They may be owned by
different user accounts crossing paths just for the pipe interaction (by
being in the same group with RW access to driver's pipe file) and not
Cheers,
Welcome on board, and adding to what Charles said, a few more thoughts:
If you get hold of effectively an embeddable third-party UPS which does its
magic with its firmware and talks USB HID to your part of the system,
99% certainly were not on par.
Like anywhere, volunteers to propose, test and document, and post PRs with
results, are very much welcome! :)
Jim
On Fri, Sep 16, 2022, 14:11 Roger Price wrote:
> On Fri, 16 Sep 2022, Jim Klimov via Nut-upsuser wrote:
>
> > Hello all,
> > Here
Hello all,
Here's a PR I want to ask community about: should NUT clients like upsc
report (log!) or hide the infamous 'Init SSL without certificate database'
message?
On one hand, it is a reminder that the setup is insecure (plaintext
protocol, might be in an externally provided tunnel but
Windoze in da NUT house!
Codebase of the NUT for Windows branch was merged to main codebase, not in
the least to avoid bit-rot and need for resynchronisation with merge
conflicts that regularly arose as the two branches "just co-existed". More
community work is needed to complete some drivers'
Hi, and nice to hear it (mostly) suits you :)
I think (OTOH so maybe docs/code can prove me wrong) that by issuing FSD
aka ForcedShutDown you yell "abandon ship, battery almost dead!" so it is
time-limited activity in real conditions.
Other than that, the "primary" (ex "master") upsmon normally
Also FWIW there should be a man page for the tool (script which those NDE
services call as their method implementation).
Sources are at
https://github.com/networkupstools/nut/blob/master/docs/man/nut-driver-enumerator.txt
On Mon, Aug 22, 2022, 00:10 Jim Klimov wrote:
> Strange that you'd see
Sorry, forgot to update the News entries.
And stumbled on terminology: since this I-D is "from community" and "not
an imternet standard", how should I correctly refer to it? :) Is the
following OK?
NUT protocol RFC published at https://www.rfc-editor.org/info/rfc9271
Thanks,
Jim
On Wed,
"Good news, everyone!"
With CI builds of the branch now regularly passing on both the
multiplatform FOSS NUT CI farm (including linux+mingw cross-builds), and
CircleCI with MacOS, and newly on AppVeyor with Windows+MSYS2 (including
integration tests with live upsd and some dummy-ups instances),
Strange that you'd see it in a 2.7.4 installation, it was added later.
The NDE is a helper script (can run standalone or wrapped into single-shot
or continuous daemon services - depends on use-case like one UPS
workstation or DCIM server watching a large dynamic population) to
configure systemd
Don't worry, many of us started as sysadmins - creative, adaptive,
investigative and sooo not stupid to get things done ;)
Can you re-run the driver without specifying a subdriver, so it would try
all of the dialects?
>From logs it seems the device indeed keeps not-replying (in time?); I
vaguely
I think yes, per code and docs it seems this is more about a unique
filename than specific directory used. Generally you might have many copies
of each, running as different unprivileged users, so one default size would
not fit all and so was deemed better not guess/default and make mistakes on
101 - 200 of 287 matches
Mail list logo
