Bug 1279294 - nut systemd dependency problem
nut systemd dependency problem
Status: NEW
Product: Fedora EPEL
Classification: Fedora
Component: nut (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-11-08 23:23 EST by Devin Reade
Modified: 2015-11-08 23:31 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Devin Reade 2015-11-08 23:23:03 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):


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:

Comment 1 Devin Reade 2015-11-08 23:24:18 EST
Anywhere I wrote "not loopback address", it's probably correct to say "not loopback or wildcard address"

Note You need to log in before you can comment on or make changes to this bug.