Description of problem: If your network is slow coming up (say you're using DHCP and the server is unavailable or rebooting after a power outage, etc) then this service might come up before the network is sufficiently configured. Recommend adding [Unit] Wants=network-online.target After=network-online.target to .service file. Version-Release number of selected component (if applicable): apcupsd-3.14.14-5.fc26.x86_64 How reproducible: Bring up host while DHCP server is down. Steps to Reproduce: 1. Provision host to use DHCP and service to use SNMP 2. Shutdown DHCP server 3. Reboot host under test Actual results: Service won't start because SNMP can't bind to an address Expected results: Service should not be started until network is adequately configured. Additional info:
In theory this was already done: * Wed Jun 22 2016 Jason L Tibbitts III <tibbs.edu> - 3.14.14-2 - Clean up the spec a bit. - Stop adding the unit file and shutdown script in a patch and just included them as sources instead. - Have the unit go after network-online.target instead of network.target. And that version is in F26. Perhaps an upgrade left the service file untouched, do you have an apcupsd.service.rpmnew lying around?
All branches of Fedora (and EPEL7) have after=network-online.target, so certainly that isn't the problem. I'm curious if Philip actually looked and saw that it wasn't there, or just assumed it wasn't there from the behavior he's seeing. There's no way you can have apcupsd.service.rpmnew, since /lib/systemd/system/apcupsd.service is not not marked %config(noreplace). Now, there could be something in /etc/systemd/system which overrides that, but... that would kind of be a local configuration bug, not a bug in this package. More likely, though, is that after=network-online.target simply isn't sufficient to guarantee the desired behavior. And I'm pretty sure it's at best racy with whatever part of the process configures the network. Not much we can do about it in the Fedora packaging ; maybe upstream might want to see a bug about dealing with changing network parameters but I suspect the answer is something crazy like "listen to dbus for messages and reconfigure yourself" which would probably just be insta-closed with some laughing. Honestly, thinking about it, I think that after=network*.target should be removed completely. apcupsd can function perfectly fine without a network. And if you need it to start after something, it's a little bit easier to add that with a drop-in than it is to remove it with one.
(In reply to Jason Tibbitts from comment #2) > All branches of Fedora (and EPEL7) have after=network-online.target, so > certainly that isn't the problem. I'm curious if Philip actually looked and > saw that it wasn't there, or just assumed it wasn't there from the behavior > he's seeing. > > There's no way you can have apcupsd.service.rpmnew, since > /lib/systemd/system/apcupsd.service is not not marked %config(noreplace). > > Now, there could be something in /etc/systemd/system which overrides that, > but... that would kind of be a local configuration bug, not a bug in this > package. > > More likely, though, is that after=network-online.target simply isn't > sufficient to guarantee the desired behavior. And I'm pretty sure it's at > best racy with whatever part of the process configures the network. Not > much we can do about it in the Fedora packaging ; maybe upstream might want > to see a bug about dealing with changing network parameters but I suspect > the answer is something crazy like "listen to dbus for messages and > reconfigure yourself" which would probably just be insta-closed with some > laughing. > > Honestly, thinking about it, I think that after=network*.target should be > removed completely. apcupsd can function perfectly fine without a network. > And if you need it to start after something, it's a little bit easier to add > that with a drop-in than it is to remove it with one. This is on a host that's been updated from FC13 all the way to F26. I added the file /etc/systemd/system/apcupsd.service as: .include /lib/systemd/system/apcupsd.service [Unit] After=network-online.target and then did "systemctl enable apcupsd.service" and that looked first in /etc/sytemd/system. This was several releases ago and it's been present since, and I've been using it successfully. I didn't notice that the target had finally been changed. But you're right: there are still conditions in which the daemon will not properly launch. I'll see if I can reproduce it. And no, it can't "function perfectly fine" if you have a large UPS with a dedicated circuit in the building and the UPS signals outages to the hosts via SNMP. In that case, you very much need the network to be up and running first or the service will fail to start. That's not always the case, of course. If you're hardwired to the UPS via a serial or USB connection, then you don't need the network at all.
It can absolutely "function perfectly fine" in the standalone case. This is documented in the apcupsd documentation. Your case may require a network. That does not mean that every use case requires a network. Anyway, there is a bug here somewhere, but I don't know where and in any case, we can't add network-online.target any more than we already have.