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): nut-2.7.2-3.el7.x86_64 How reproducible: 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 4. Reboot 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 Additional info: 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: http://unix.stackexchange.com/questions/126009/cause-a-script-to-execute-after-networking-has-started
Anywhere I wrote "not loopback address", it's probably correct to say "not loopback or wildcard address"
I understand that this makes it more complicating, but as it's not the most used scenario, as no other bug reports and no huge CC list suggest, this is part of the configuration that is required to make it work for mentioned use case. I'm closing this as wontfix for now, may reconsider later.