Use target for drivers in systemd

[miska]

This allows much better granularity and better monitoring in case of
multiple UPSes. Also provides ability to restart individual UPSes.

[clepple]

Does this require a specific minimum systemd version number?

[aquette]

Also, this seems to be a generic (template-like) format, that would require some runtime instantiation for nut-driver@.service (iterate on ups.conf entries, then call nut-driver@.service...)
Could you please provide some details / doc on how to use this practically?

[aquette]

ok, I think I got it probably:
by calling (for example) "systemctl start nut-driver@devname start" and having a section "[devname]" in ups.conf, systemd will do the runtime instantiation, and in turn the unit will call "upsdrvctl start devname", that's it?

but then, though I see the benefit for manual calls, I'm still failing to identify how the current behavior is achieved. i.e. have all drivers started when calling "systemctl start nut-driver start"

@miska thanks to shed some light on this.

[miska]

You call "systemctl enable nut-driver@devname start" for every UPS in your configuration file that you want to have started and then you can start/shutdown all of the selected by using "systemctl start/stop nut.driver.target"

Advantages are that you can restart only one UPS which configuration changed without need to restart everything. And you can also disable some UPS for which you have configuration present in your config file but you do not have present in the moment - for example some maintenance.

[peterhoeg]

@miska wouldn't it make more sense to have the driver only be WantedBy=nut-driver.target and then have the nut-driver.target have an install section:

[Install]
WantedBy=multi-user.target

[jimklimov]

@peterhoeg @miska @aquette : It seems this approach would also help retain the systemctl enable/start/stop/disable nut-driver behavior, since the short-hand notation would pick the most-matching full unit name (nut-driver.target if a .service is not provided) and so toggle the target's state and automatically that of all enabled driver instances. At least that's the theory, not too hard to test ;)

[jimklimov]

Suggestion above was included in #330 which, if acceptable, fully includes and then supersedes this older PR.

[aquette]

Closing the present PR in favor of #330