<div dir="ltr"><div dir="ltr"><div>Hello,</div><div><br></div><div> I think this should be possible, probably with dummy-ups or clone* drivers and respective override.* definitions in the "secondary drivers"</div><div><br></div><div> 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?)<br></div><div><br></div><div> 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@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.</div><div><br></div><div> 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).<br></div><div><br></div><div> 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.<br></div><div><br></div><div> 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@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.<br></div><div><br></div><div>Hope this helps,<br></div><div>Jim Klimov<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 13, 2023 at 9:30 AM Steffen Grunewald <<a href="mailto:steffen.grunewald@aei.mpg.de">steffen.grunewald@aei.mpg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning NUTcrackers,<br>
<br>
several years ago, I had a setup that used the SNMP driver to collect data<br>
from a networked UPS and act as a source for multiple "secondary" drivers<br>
that each had a different battery level to trigger various actions, e.g.<br>
at 70% shut down some services, at 50% freeze the batch system and at 30%<br>
switch off everything but the spinning disks (leave JBODs running, change<br>
runlevel to 1).<br>
<br>
My attempts to clone the old setting for a recent version of NUT (2.8.0,<br>
backported from sid a few months ago) failed to start the set of drivers,<br>
so something must have changed while I wasn't looking.<br>
<br>
Is this approach still possible with NUT 2.8.x, and may I learn from<br>
someone who is running such a setup?<br>
<br>
Thanks in advance,<br>
Steffen<br>
<br>
-- <br>
Steffen Grunewald, Cluster Administrator<br>
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)<br>
Am Mühlenberg 1 * D-14476 Potsdam-Golm * Germany<br>
~~~<br>
Fon: +49-331-567 7274<br>
Mail: steffen.grunewald(at)<a href="http://aei.mpg.de" rel="noreferrer" target="_blank">aei.mpg.de</a><br>
~~~<br>
<br>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div></div>