Bug 1292052 - Doesn't function properly when started before network is available (with network UPS)
Doesn't function properly when started before network is available (with netw...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: apcupsd (Show other bugs)
24
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-16 05:55 EST by Ferry Huberts
Modified: 2017-08-08 08:33 EDT (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Ferry Huberts 2015-12-16 05:55:12 EST
Description of problem:
When apcupsd is started _without_ waiting for the network to be up, then the software doesn't function properly and does _not_ recover.

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. configure apcupsd for a network UPS, for example:

UPSCABLE     ether
UPSTYPE      snmp
DEVICE       192.168.1.1:161:APC:private
POLLTIME     30
BATTERYLEVEL 10
MINUTES      10

2. enable and start

systemctl enable  apcupsd.service
systemctl restart apcupsd.service

3. reboot

4. run

apcacess

--> The UPS data is not available and will not be even after multiple POLLTIMEs



Additional info:


I need to add

# apc sw doesn't start properly when there is no network yet
systemctl enable NetworkManager-wait-online.service


to work around this
Comment 1 Ferry Huberts 2015-12-16 05:56:06 EST
Version-Release number of selected component (if applicable):
apcupsd-3.14.13-4.fc23.x86_64

(but has been present for a loooong time, only now came to filing a bug)
Comment 2 Fedora Admin XMLRPC Client 2016-06-22 11:43:39 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 3 Fedora Admin XMLRPC Client 2016-06-22 15:18:33 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 4 Jason Tibbitts 2016-06-22 16:22:48 EDT
I've just taken over this package and am looking through the tickets.

The Fedora package actually uses the upstream unit file, but my understanding of the network issue is that it is indeed not sufficient to use After=network.target.

Can you disable the NetworkManager-wait-online service, and drop this into /etc/systemd/system/apcupsd.service.d/apcupsd.conf:

[Unit]
After=network-online.target

then systemctl daemon-reload and then do your usual tes5ting and let me know if that's any better?  You can delete that file and the apcupsd.service.d directory after testing if you like.

I'm going to go ahead and just make the change in at least the rawhide package now, but it would be good to have confirmation.
Comment 5 Jason Tibbitts 2016-06-22 21:24:56 EDT
Also, I was wrong; upstream doesn't provide a unit file at all.  For some reason it was being included in the Fedora package by way of a patch, not as actual files.  I've fixed that up and made sure that the daemon starts after network-online target, at least on rawhide.  I'll submit an update after I've done a bit more testing.
Comment 6 Ferry Huberts 2016-07-21 10:40:12 EDT
(In reply to Jason Tibbitts from comment #4)
> I've just taken over this package and am looking through the tickets.
> 
> The Fedora package actually uses the upstream unit file, but my
> understanding of the network issue is that it is indeed not sufficient to
> use After=network.target.
> 
> Can you disable the NetworkManager-wait-online service, and drop this into
> /etc/systemd/system/apcupsd.service.d/apcupsd.conf:
> 
> [Unit]
> After=network-online.target
> 

Doesn't work.

The test is to reboot, then login and then see that apcaccess doesn't show ups data (for me, with a SNMP base APC ups)


> then systemctl daemon-reload and then do your usual tes5ting and let me know
> if that's any better?  You can delete that file and the apcupsd.service.d
> directory after testing if you like.
> 
> I'm going to go ahead and just make the change in at least the rawhide
> package now, but it would be good to have confirmation.
Comment 7 Ferry Huberts 2016-07-21 10:41:41 EDT
And it seems that even enabling NetworkManager-wait-online service is no longer sufficient
Comment 8 Ferry Huberts 2016-07-21 10:44:42 EDT
Setting 'After=network-online.target' in /lib/systemd/system/apcupsd.service also doesn't work
Comment 9 Ferry Huberts 2016-08-12 07:49:24 EDT
On F24 this is seriously biting me (now installing F24 servers)

I have resorted to:


# apc sw doesn't start properly when there is no network yet
cat > /etc/NetworkManager/dispatcher.d/99-apcupsd << "EOF"
#!/bin/sh
# This is a NetworkManager dispatcher script for apcupsd to restart

export LC_ALL=C

if [ "$2" = "up" ]; then
	systemctl restart apcupsd.service &> /dev/null
fi

exit 0
EOF
Comment 10 Ferry Huberts 2016-10-06 05:43:22 EDT
(In reply to Ferry Huberts from comment #9)
> On F24 this is seriously biting me (now installing F24 servers)
> 
> I have resorted to:
> 
> 
> # apc sw doesn't start properly when there is no network yet
> cat > /etc/NetworkManager/dispatcher.d/99-apcupsd << "EOF"
> #!/bin/sh
> # This is a NetworkManager dispatcher script for apcupsd to restart
> 
> export LC_ALL=C
> 
> if [ "$2" = "up" ]; then
> 	systemctl restart apcupsd.service &> /dev/null
> fi
> 
> exit 0
> EOF

#!/bin/bash

# This is a NetworkManager dispatcher script for apcupsd to restart since
# apcupsd doesn't start properly when there is no network yet

set -u


set +e
systemctl -q is-enabled apcupsd.service 2> /dev/null
if [ $? -ne 0 ]; then
  exit 0
fi
set -e

if [ "$2" = "up" ]; then
  systemctl restart apcupsd.service &> /dev/null
fi
Comment 11 Fedora End Of Life 2017-07-25 15:38:52 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 12 Fedora End Of Life 2017-08-08 08:33:47 EDT
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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