I've installed and run apcupsd in two machines running Gentoo-Linux with systemd and found that, if one of them is configured as a slave connected through the network to the master (the one to which the APC SAI is physically connected by means of the usb cable), I get some errors in the slave machine related to the fact that the network device is not yet working and active when the apcupsd starts. More precisely, in the slave machine the errors are related to the access to the (mail) smtp server because the network device is not yet fully functional. I've solved the problem in the slave machine editing /usr/lib/systemd/system/apcupsd.service and adding in the [Unit] section: Wants=network-online.target After=network-online.target It seems that this should be added to the default apcupsd.service
Created attachment 486464 [details, diff] Update to systemd service file to depend on the network
(In reply to miguelramos from comment #0) > Wants=network-online.target > After=network-online.target > > It seems that this should be added to the default apcupsd.service Thanks for the suggestion, I've attached a patch matching this. The openrc file has a 'use net' dependency already so updating the apcupsd.service to match.
Please, let me make two more comments/suggestions. When the service starts, to avoid that, from a badly driven AC power off, "powerfail" might remain in /etc/apcupsd/, it seems that the apcupsd.service file should also include ExecStartPre=/bin/rm -f /etc/apcupsd/powerfail mimicking the way openrc solves this problem. The second comment is related to killing power in the APC SAI after apcupsd orders a shutdown to avoid battery draining. As the systemd apcupsd.service is configured now and following the openrc style, this could be achieved by adding a script in /usr/lib/systemd/system-shutdown/ to get what apcupsd.powerfail does in openrc. However, a close colleague officially devoted to develop OpenBSD tells me that the simplest solution is what they have implemented in OpenBSD that always starts acpupsd with flag --kill-on-powerfail that I have checked works with our Back-UPS 650 contrary to what seems to be suggested in the apcupsd man page. I haven't yet tested "the script in system-shutdown" approach in Gentoo-systemd because from now on and during one month our SAI will be driven by our mail server running OpenBSD since the two Gentoo-systemd machines will be off. This is the reason I know very well that the OpenBSD approach with --kill-on-powerfail by default works correctly (in master mode and with no problem in slave mode) with the Back-UPS 650 model. I positively know that using the KILLDELAY directive in apcupsd.conf instead does not work in Gentoo-systemd at least using /sbin/shutdown to power off, although I have clues that it might work using "systemctl poweroff" instead of /sbin/shutdown.
Please see the discussion in https://github.com/gentoo/gentoo/pull/5172 Current status (from 2017-07-23): I tend to reject the PR. The bug reporter (miguelramos) cannot expect that we ship a systemd service which works with all possible configurations out of the box. apcupsd isn't primarily a network service. If you use it as network service (listener or connect via network) you are supposed to adjust your init system accordingly. In this specific case, for systemd, you should create /etc/systemd/system/acpupsd.d/require-network.conf with content like [Unit] Wants=network-online.target After=network-online.target to overwrite default service. But I was told that this maybe don't actual solve the problem for all possible configurations. I.e. without systemd-networkd-wait-online.service enabled, this isn't always doing what you might expect. And if you depend on a working name resolution because you are using a FQDN in your CFG you have to ensure that acpupsd service also starts after the service providing name resolution. The only reason why I haven't rejected the PR yet is that we ship "use net" in OpenRC's runscript. I am waiting for feedback to either remove "use net" from OpenRC's runscript as well (for the same reason) or add at least an "After=" to the systemd service. However, systemd folk told me, due to systemd-networkd-wait-online.service, the "Wants=" doesn't really hurt much ... so currently it all comes down to the question whether we want to do it right or it should just work for some more setups.
As a side note, in Fedora they are relying only in "After=" for network-online requirement, they don't specify it as "Wants=" too: https://src.fedoraproject.org/cgit/rpms/apcupsd.git/plain/apcupsd.service Also, regarding the removal of powerfail file, even if Fedora is also removing it with "rm" from the service file, probably another option could be to provide a tmpfiles file with something like: r /etc/apcupsd/powerfail in its contents Also, adding network-online in "After=" won't have any impact for people not wanting to play with networking at all. Those with network-online enabled will get the benefits from getting it started before apcupsd wants to be run, and it won't neither impact for people not having network-online enabled
Being more precise, the problem about using --kill-on-powerfail with a non smart APC UPS is that the preconfigured grace time for the device to actually disconnect the power to the computers and going to sleep cannot be changed because there is no configurable eprom like in the Smart models. You do not want to turn power off before your computers have effectively shut down. I suppose the KILLDELAY directive in apcupsd.conf is there as a workaround for this, although I have not test it together with --kill-on-powerfail active. It seems that this grace time is about 60 seconds in non smart APC devices and the master machine driving the UPS (SAI in Spanish, sorry because sometimes I've used it in English) should spend less than 60 seconds in the process of shutting down to cleanly accomplish it. It is worth to notice that in systemd the "DefaultTimeoutStopSec" equals 90 seconds and recently I've seen it many times running for 90 seconds during shutdown and/or reboot because of (unknown to me) processes related to user "gdm" in the 7 machines with Gentoo-Systemd I use and maintain (a "gdm" bug?).
(In reply to Pacho Ramos from comment #5) > As a side note, in Fedora they are relying only in "After=" for > network-online requirement, they don't specify it as "Wants=" too: > https://src.fedoraproject.org/cgit/rpms/apcupsd.git/plain/apcupsd.service That's probably a mistake. See systemd.special for how network-online.target is supposed to work: "Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it." I suppose they might intentionally leave out the Wants= to cause network-online.target to not be activated unless some OTHER service also depends on it, but a mistake seems more likely to me.
Like written in https://github.com/gentoo/gentoo/pull/5172#issuecomment-317205795 this PR was rejected. apcupsd isn't a network service per default. If you require network to run apcupsd you have to adjust your depedencies.
