Red Hat Bugzilla – Bug 1279294
nut systemd dependency problem
Last modified: 2015-11-08 23:31:10 EST
Description of problem:
If you have a LISTEN parameter set in upsd.conf for something that is not the loopback address, then the NUT daemon will fail to start when booting the machine cold. The reason is that there is a timing issue between when systemd thinks it can start nut-server and when the real dependencies are actually fulfilled. Systemd is trying to start nut-server as soon as the network "is available" but before it configures any actual non-loopback network addresses. Therefore when upsd tries to start, it can't listen on the given IP (because it's not yet configured) and fails.
Running "systemctl start nut-server" manually after boot works. It is only when rebooting the machine that the failure occurs.
The fix is to modify /lib/systemd/system/nut-server.service and in the "After" clause where "network.target" appears, also add in "network-online.target".
It is also necessary to execute the following, although it is unclear if this falls into the realm of a nut bugzilla item:
systemctl enable NetworkManager-wait-online.service
If this isn't handled as part of the install, then it should at least be documented somewhere obvious.
Version-Release number of selected component (if applicable):
On a CentOS 7 minimal install on fast hardware, the UPS server will fail to start every time. I don't know how reproducable it will be on slower hardware or a non-mimimal install.
Steps to Reproduce:
1. Set the LISTEN parameter in /etc/ups/upsd.conf to a non-loopback address
2. Configure nut-server and nut-client appropriately and verify that when
manually started via "systemctl start nut-server", the daemon comes up
and the client is able to talk to the daemon (such as getting the status
via the "upsc" command).
3. Set the daemon to start on boot via:
systemctl enable nut-monitor
systemctl enable nut-server
5. Observe that upsc fails in that it cannot talk to the daemon
6. Observe that "systemctl status nut-server" shows that the daemon failed
to start with a address binding error
Seeing how few packages use the network-online target as a dependency, it makes me wonder if this is an endemic problem for many daemons when they're configured to not use the loopback or wildcard address.
When diagnosing this, the following URL was of assistance:
Anywhere I wrote "not loopback address", it's probably correct to say "not loopback or wildcard address"