Bug 994323 - Delay needed after upsdrvctl shutdown
Delay needed after upsdrvctl shutdown
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts (Show other bugs)
6.5
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Lukáš Nykrýn
Jan Ščotka
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-07 00:11 EDT by Tom Lane
Modified: 2016-11-25 07:59 EST (History)
5 users (show)

See Also:
Fixed In Version: initscripts-9.03.47-1.el6
Doc Type: Bug Fix
Doc Text:
please see https://bugzilla.redhat.com/show_bug.cgi?id=994323#c6 I did what was written there, but I have no idea how ups works.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-22 03:18:13 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 Tom Lane 2013-08-07 00:11:14 EDT
Description of problem:
I've been trying to get UPS shutdown to work with an APC RS 1000.  After much hair-pulling I found out that this makes it work:

$ diff -c /etc/rc.d/init.d/halt.orig /etc/rc.d/init.d/halt     
*** /etc/rc.d/init.d/halt.orig  Wed Jan  9 06:13:29 2013
--- /etc/rc.d/init.d/halt       Tue Aug  6 23:36:51 2013
***************
*** 199,204 ****
--- 199,205 ----
        fi
        if [ "$SERVER" = "yes" -a -f $POWERDOWNFLAG ]; then
                /sbin/upsdrvctl shutdown
+               sleep 5
        fi
  fi
  
I speculate that upsdrvctl forks off the driver and doesn't wait for it to actually finish telling the UPS to shut down.  If we fall through to the kernel halt before that command has been issued, it doesn't get issued.

I suspect that upstream won't think this is a bug, since their recommendation for calling "upsdrvctl shutdown" involves a sleep and then a reboot anyway.
But it's definitely a problem with the current RHEL6 initscript.

Version-Release number of selected component (if applicable):
nut-2.6.5-2.el6.x86_64

How reproducible:
seems 100%

Steps to Reproduce:
1. configure a USB UPS on a reasonably fast RHEL6 machine
2. upsmon -c fsd

Actual results:
UPS doesn't turn off, so system must be rebooted manually

Expected results:
UPS should turn off for a moment and then restore power

Additional info:
Comment 1 Michal Hlavinka 2013-08-13 10:03:52 EDT
valid request, reassigning to initscripts
Comment 3 Lukáš Nykrýn 2013-08-14 07:14:18 EDT
Yes we can add sleep, but It would be better to fix the issue instead of workaround. Michal is it possible to add some "more synchronous" switch to nut. I assume that similar issue will be in cooperation of nut and systemd.
Comment 4 Michal Hlavinka 2013-08-14 10:54:09 EDT
OK, I reread the bug description and checked the nut sources.
The upsdrvctl does fork-exec-waitpid, so it should exit after shutdown command was sent to the UPS.

Tom, could you tell me what configuration you use?
Run following command and attach it's output here. Thanks

grep -rv '^#' /etc/ups/ | grep -v ':$' | grep -v '.html:'
Comment 5 Tom Lane 2013-08-14 13:45:09 EDT
Huh, that's interesting.  My config is pretty vanilla:

/etc/ups/upsd.users:[admin]
/etc/ups/upsd.users:	password = xxxx
/etc/ups/upsd.users:	actions = SET
/etc/ups/upsd.users:	instcmds = ALL
/etc/ups/upsd.users:[monuser]
/etc/ups/upsd.users:	password = xxxx
/etc/ups/upsd.users:	upsmon master
/etc/ups/upsmon.conf:MONITOR sss1_ups@localhost 1 monuser xxxx master
/etc/ups/upsmon.conf:MINSUPPLIES 1
/etc/ups/upsmon.conf:SHUTDOWNCMD "/sbin/shutdown -h +0"
/etc/ups/upsmon.conf:POLLFREQ 5
/etc/ups/upsmon.conf:POLLFREQALERT 5
/etc/ups/upsmon.conf:HOSTSYNC 15
/etc/ups/upsmon.conf:DEADTIME 15
/etc/ups/upsmon.conf:POWERDOWNFLAG /etc/killpower
/etc/ups/upsmon.conf:RBWARNTIME 43200
/etc/ups/upsmon.conf:NOCOMMWARNTIME 300
/etc/ups/upsmon.conf:FINALDELAY 5
/etc/ups/ups.conf:[sss1_ups]
/etc/ups/ups.conf:	driver = usbhid-ups
/etc/ups/ups.conf:	port = auto
/etc/ups/ups.conf:	offdelay = 30
/etc/ups/ups.conf:	ondelay = 40
/etc/ups/ups.conf:	desc = "APC RS 1000"
/etc/ups/upssched.conf:CMDSCRIPT /usr/bin/upssched-cmd

The machine I'm using is a dual CPU (8 core) x86_64 box.  I don't know much about the USB hardware it has, but it seems entirely clear from my testing that the UPS doesn't recognize the shutdown command if the kernel is allowed to close down with no delay.
Comment 6 Michal Hlavinka 2013-08-16 04:41:55 EDT
I tried to reproduce this, but was not successful.
Anyway, that delay should be there and if it fixes it for you, it's good enough solution.

Lukas, please change the halt section. this way:
  if [ "$SERVER" = "yes" -a -f $POWERDOWNFLAG ]; then
        /sbin/upsdrvctl shutdown
+       sleep 120
+       /sbin/reboot --force
  fi

This is standard way to make it work out of the box with all different UPSes out there. When battery goes low, ups sw  asks system to shutdown, but when AC power comes back during the shutdown process, some UPSes won't turn the power Off - On to start the system again and just keep power on all the time. That's why the sleep is there. In normal circumstances UPS will power off a few seconds after it gets shutdown command, but when it does not, system would be halted with power on forever (until angry administrator comes and kicks the reset button). That why the reboot is there - if there is no power off, reboot the system so it's fully working again.
Comment 7 Tom Lane 2013-08-16 11:05:19 EDT
Yeah, that's what I was alluding to in the initial report --- nut upstream isn't going to think the need for a delay is a bug, because the above coding is exactly what they recommend to be fail-safe in case the UPS fails to honor the shutdown command for some reason.  +1 for doing it like they say to.
Comment 8 RHEL Product and Program Management 2013-10-13 22:49:52 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 14 errata-xmlrpc 2015-07-22 03:18:13 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1380.html

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