Fix systemd service file for Debian (depend on systemd-udev-settle.service)

[jimklimov]

Upstreaming fixes applied to our project at work

From: Laurent Bigonville bigon@debian.org
Forwarded: not-needed

[jimklimov]

@bigon @peterhoeg : would you like to look at this, particularly if it is nowadays needed?

We have the patch applied on a project at work, and at least it does not seem to break anything ;)

[bigon]

The only problem with the systemd-udev-settle.service service is that it can make the boot slower.

IMHO, upsdrvctl should grow some udev dependency to check if the needed usb devices are present or not

[jimklimov]

Do I read it right that it should generally also grow a bit of dependency or other logic for cases where it does not track USB UPSes so would not care for this service at all?

[jimklimov]

Also this subject is probably related to #330 (which now also includes a variant of this patch). Maybe generators described by Peter could be a solution for depending a particular instance of the driver service on udev, and ignoring it in other instances...

[jimklimov]

FYI : The solution in PR #330 has been extended this weekend to generate drop-in configuration snippets for service unit instances that wrap each NUT config section individually, so for device drivers considered to be USB-related this dependency would be added - and won't impede startup of other drivers. (Testing needed though).

[peterhoeg]

According to upstream systemd using systemd-udev-settle.service is the "wrong way" as there is technically no point in time where "all devices have shown up".

How about having udev launch the service instead when the device shows up?

[jimklimov]

Discussed this option with @aquette - there are many devices on the market with too many corners cut when making USB controllers (and other components), so they reset "occasionally". Some do so every few seconds. If we fully stop-start drivers all the time on such USB events, they might not even have enough time to initialize :(

On the other hand, NUT drivers by themselves might not even notice the event, or if it falls out during the polling - then a cycle iteration would be botched but a next one would likely succeed. So data will be marked stale (or just not updated) for a short while, presumably.

[jimklimov]

I guess the point of this PR becomes moot as #330 offers a better (more flexible) solution which also covers this use-case (thanks to attention caused by the patch which started this PR though).