Nut upsuser - Sep 2023 - Multiple battery levels to trigger actions?

Good morning NUTcrackers,

several years ago, I had a setup that used the SNMP driver to collect data
from a networked UPS and act as a source for multiple "secondary"
drivers
that each had a different battery level to trigger various actions, e.g.
at 70% shut down some services, at 50% freeze the batch system and at 30%
switch off everything but the spinning disks (leave JBODs running, change
runlevel to 1).

My attempts to clone the old setting for a recent version of NUT (2.8.0,
backported from sid a few months ago) failed to start the set of drivers,
so something must have changed while I wasn't looking.

Is this approach still possible with NUT 2.8.x, and may I learn from
someone who is running such a setup?

Thanks in advance,
 Steffen

-- 
Steffen Grunewald, Cluster Administrator
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
Am M?hlenberg 1 * D-14476 Potsdam-Golm * Germany
~~~
Fon: +49-331-567 7274
Mail: steffen.grunewald(at)aei.mpg.de
~~~

Hello,

  I think this should be possible, probably with dummy-ups or clone*
drivers and respective override.* definitions in the "secondary
drivers"

  So if something does not work here, I'm ready to consider it a bug. Can
you post samples of config and logs (are there any errors?)

  One thing that comes to mind quickly: with NUT 2.8.0+ we deliver a new
`nut-driver-enumerator` (script and service) which when enabled, looks at
ups.conf contents and its real-time changes, and can generate unit
instances for nut-driver at SectionName (a bit more complicated than that in
the most general case, not all name patterns are valid for systemd or SMF
that this approach supports - can be MD5 hashes of the section name then).
As part of such definitions, it describes "After" and
"Wants" dependencies
based on driver type (e.g. not all of them are tied to networking). A
possible caveat here is that one driver depending on another, and depending
on an upsd data server, while any driver generally also being a dependency
for upsd to start - this may require manual addition of systemd
"drop-in"
files to untangle the dependencies.

  Note that this entanglement concerns primarily the service definitions.
Daemons themselves are relatively independent, with `upsd` capable of
polling the FS if socket files appear so they would pick up a driver
(re-)started after the data server began running. Nowadays there is also an
option for `upsd` to allow starting if currently there are no devices
listed in `ups.conf`, so it can be reloaded with a signal later - after the
file becomes populated (e.g. to behave predictably on a newly deployed
monitoring appliance). Generally a driver also can start and live
independently of `upsd` appearing or going away. A `dummy-ups` or `clone*`
driver might however refuse to start if it can not read its data source
which it relays further - e.g. if the `upsd` is not yet running or serving
the "original" driver data (snmp-ups in your case).

 Something to try here is to check if such units do exist, and if yes - to
start them (or even for experiments - directly start the daemons via
command-line, without a service unit). If I guess the default situation
correctly, after boot you would have snmp-ups running, and possibly upsd
(if a failed cloning driver did not preclude its start as the nut-server
systemd unit). Hopefully after some time any failed clone driver units
would retry starting after a quiet timeout, and would find the upsd and
snmp-ups's data on it. If however systemd decides there is a dependency
loop, it might decide to never (re-)start something, in order to avoid the
loop - either clone driver units or nut-server.

  If such simple attempts prove that the daemons and configurations CAN
still work like this (no regression in NUT itself), then a drop-in file for
each clone driver unit like
/etc/systemd/system/nut-driver at dummy1.service/customdeps.conf
could be used (see man pages for your systemd version to be sure about the
syntax) to e.g. remove the backwards "Install" dependency like
`WantedBy=nut-server.service` (probably by specifying a blank `WantedBy=`)
so that the loop would be no more, and ensuring there is a  "Service"
section dependency set of `Wants=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.grunewald at aei.mpg.de> wrote:
> Good morning NUTcrackers,
>
> several years ago, I had a setup that used the SNMP driver to collect data
> from a networked UPS and act as a source for multiple "secondary"
drivers
> that each had a different battery level to trigger various actions, e.g.
> at 70% shut down some services, at 50% freeze the batch system and at 30%
> switch off everything but the spinning disks (leave JBODs running, change
> runlevel to 1).
>
> My attempts to clone the old setting for a recent version of NUT (2.8.0,
> backported from sid a few months ago) failed to start the set of drivers,
> so something must have changed while I wasn't looking.
>
> Is this approach still possible with NUT 2.8.x, and may I learn from
> someone who is running such a setup?
>
> Thanks in advance,
>  Steffen
>
> --
> Steffen Grunewald, Cluster Administrator
> Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
> Am M?hlenberg 1 * D-14476 Potsdam-Golm * Germany
> ~~~
> Fon: +49-331-567 7274
> Mail: steffen.grunewald(at)aei.mpg.de
> ~~~
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230913/8f326854/attachment.htm>