[Nut-upsuser] SNMPv3 fails when more than one UPS is configured in ups.conf
Lee Damon
nomad at ee.washington.edu
Tue Dec 5 16:24:57 UTC 2017
>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
More information about the Nut-upsuser
mailing list