Nut upsuser - Dec 2017 - SNMPv3 fails when more than one UPS is configured in ups.conf

I have it "working" with the following settings changes from the
default
in the RPM. By "working" I mean it starts after reboot and after
issuing
'sudo systemctl restart nut-driver' but, as expected, it takes quite a
while to finish startup.

/etc/systemd/system/nut-driver.service.d/nut-driver.conf
[Unit]
StopWhenUnneeded=no

[Service]
TimeoutSec=600



/etc/ups/ups.conf
...
maxretry = 10
retrydelay = 15
...


As I said, I suspect the bulk of these are cargo cult "it worked, not
messing with it" settings.

nomad

On Dec 4, 2017, at 2:43 PM, Lee Damon <nomad at ee.washington.edu>
wrote:
> 
> I have it "working" with the following settings changes from the
default
> in the RPM. By "working" I mean it starts after reboot and after
issuing
> 'sudo systemctl restart nut-driver' but, as expected, it takes
quite a
> while to finish startup.
Yeah, this doesn't sound ideal.

How close do the EPEL RPM's systemd configuration files look to the ones in
the NUT tree? e.g.
https://github.com/networkupstools/nut/blob/v2.7.2/scripts/systemd/nut-driver.service.in

If the EPEL RPMs have a bug tracker, it might be worth pinging them about it.
The "StopWhenUnneeded=no" part is odd, in my mind, although the idea
is for "upsdrvctl start" to start the drivers, let them fork, then
exit. (Were you running "upsdrvctl -D start" at the command line or
under systemd? I would not expect the latter to work without modifications.)

There is also a proposal for reworking the NUT driver startup under systemd, in
case problems crop up later, and you want to revisit this:

https://github.com/networkupstools/nut/pull/330

As I understand it, the drivers would each get their own systemd unit, so that
might be easier for isolating failures.

>How close do the EPEL RPM's systemd configuration files look to the
ones in the NUT tree?

The only difference between?/lib/systemd/system/nut-driver.service and
the one
at?https://github.com/networkupstools/nut/blob/v2.7.2/scripts/systemd/nut-driver.service.in
(not counting variable substitution for paths) is an additional line in
the [Service] section provided by EPEL:

ExecStartPre=-/usr/bin/systemd-tmpfiles --create
/etc/tmpfiles.d/nut-run.conf
>?The "StopWhenUnneeded=no" part is odd, in my mind, although the
idea
is for "upsdrvctl start" to start
> the drivers, let them fork, then exit. (Were you running "upsdrvctl -D
start" at the command line or under
> systemd? I would not? expect the latter to work without modifications.)
I've left all systemd files intact except for having to add the
StopWhenUnneeded=no (along with change to TomeoutSec) to
/etc/systemd/system/nut-driver.service.d/nut-driver.conf. I presume the
default is to run it without -D.?

Even with the extended timeouts I've seen upsdrvctl start take 4 or 5
tries to start a driver (sometimes it takes multiple tries to start
multiple drivers). I've even seen it take multiple tries for the very
first driver. Even with the extended timeouts it has failed to start on
one reboot out of three.

I suspect there's a deeper problem here. This morning I came in to 22
emails about COMBAD and 22 emails about COMOK from upsmon on the master
host and a bunch more such messages from upsmon on my test clients. The
time between BAD and OK is almost always 5 seconds (I presume this is
the retry timer setting). Oddly enough, the complaint times on the test
clients don't always match up with the complaint times on the master.
Sometimes they both complain at the same time, sometimes the master
complains but the client doesn't, and some times the client complains
but the master doesn't. I don't remember seeing this at all when I was
using SNMPv1 but I didn't use that for very long so it's possible I just
didn't see it because it hadn't happened yet. I think I'm going to
switch the config to SNMPv1 for a while and see if the problem persists.

nomad