upsd.conf: document race with LISTEN on specific interfaces

[clepple]

If a LISTEN option is encountered in upsd.conf before the interface is fully configured, upsd may fail to start. Tagged systemd because it seems that other init systems tend to wait until the interfaces are all configured before starting NUT.

See also #392.

[clepple]

Links from Manuel Wolfshant:

• https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
• http://stackoverflow.com/questions/32873571/debian-systemd-service-starts-before-network-is-ready

[jimklimov]

I wonder if there is a possibility for a single solution to rule them all?

We can have:

• upsd listening just on localhost for the local upsmon to drive graceful shutdowns; for a local-media UPS or even a battery (if we get to wrap those with NUT drivers), this can work to protect systems without any real network - probably needs the system to start up loopback networking though;
• upsd normally listening on "any" (*) interface - whatever is currently "up" so kernel delivers the packets to the daemon;
• upsd listening on particular interface or address - and those may be dynamic (dhcp, usb-plug, etc.)

Is there some one systemd unit that wraps such networking use-cases for upsd service unit to "Require" or at least "Want" and start up "After"? On a similar note, in case of plug'n'play networking, including change of IP addresses and/or link-down/link-up events (but with the set of NICs remaining the same), do we want upsd to reconfigure or restart by venue of service dependencies?

But other than that, we can indeed pre-package the unit file with several commented-away variants of the setup and document the issue and when/how to tune it. As an implementation detail, we can follow suggestions posted by @peterhoeg in PR #330 - using the "drop-in configuration fragments without changing the unit file" which might be friendlier to packaging and more visible to local system administration.

The question of dependency on plug'n'play networking hardware may be related to udev on Linux, so also referencing PR #377 as something we may want to consider (in pre-set configs or at least note in documentation).

[peterhoeg]

@jimklimov , you typically have 2 network targets:

• network.target
• network-online.target

The former should be a safe bet, as all the network interfaces present at boot would be visible although they may not be configured yet.

How does upsd handle it if asked to listen on an unconfigured interface that subsequently is configured after upsd has started?

[clepple]

@peterhoeg the answer to your last question may be complicated by a logic bug (depending on whether the interface is the first in the configuration file), but the intent was to fail fast if the configuration did not match the interfaces at the time that upsd started.

[mrjackson]

In upsd.conf, use LISTEN 0.0.0.0 3493 instead of anything else and the issue "goes away".

The first link that @clepple posted explains why and what should be done in the last section.