Project

General

Profile

Bug #7675

upsmon.conf and rc.shutdown missing functionality to actually shutoff the UPS

Added by Vagelis Savvas over 5 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Nice to have
Assignee:
Josh Paetzel
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

The upsmon.conf doesn't include the POWERDOWNFLAG line
so the /etc/killpower flag file never gets created.
In addition, the /etc/rc.shutdown script doesn't contain code
to check for the existance of /etc/killpower and initiate
the UPS shutoff in case the file is there, as described in NUT documentation.
End result is that on power failure the UPS continues indefinately to provide
backup power to the connected computer, even after its OS has been cleanly shutdown.
That means that the UPS doesn't do its poweroff-poweron
cycle and the connected computer never gets a change to power on,
provided its BIOS is configured appropriately to "Stay always ON".

Associated revisions

Revision c5b1b52a (diff)
Added by Josh Paetzel over 5 years ago

Send a UPS the power down signal when the UPS trips a system poweroff Ticket: #7675

Revision 1a270305 (diff)
Added by Josh Paetzel over 5 years ago

Send a UPS the power down signal when the UPS trips a system poweroff Ticket: #7675 (cherry picked from commit c5b1b52a9d0823f6ca806f55fae2a0d96fd41e5f)

History

#1 Updated by Josh Paetzel over 5 years ago

  • Status changed from Unscreened to Screened
  • Assignee set to Josh Paetzel

#2 Updated by Josh Paetzel over 5 years ago

  • Status changed from Screened to Resolved

Would it be possible for you to test this in tonight's nightly? It will have the changes that should make this work.

#3 Updated by Panagiotis Kritikakos over 5 years ago

I have tested these changes and they seem to work OK.

#4 Updated by Vagelis Savvas over 5 years ago

The changes are fine, thanx!

#5 Updated by Josh Paetzel over 5 years ago

  • Status changed from Resolved to Ready For Release
  • Target version set to Unspecified

#6 Updated by Jordan Hubbard over 5 years ago

  • Status changed from Ready For Release to Resolved

#7 Updated by Cyber Jock over 5 years ago

So is this enabled for everyone? Sure looks like it to me. The reason I ask is that for some UPSes, if you turn them off in this fashion they will:

1. Sometimes cut off power to the server before the server is off (which defeats the purpose of the UPS in the first place)
2. Some models of UPS do not turn themselves back on. You must locally touch the UPS to power it on.

#8 Updated by Vagelis Savvas over 5 years ago

For 1. you can use the UPS parameter ups.delay.shutdown (http://www.networkupstools.org/docs/user-manual.chunked/apcs01.html). The /etc/rc.shutdown script should send the shutoff command to the UPS as the last thing it does.
At that point the OS shutdown sequence should be on its very last stages so you have to measure how much time it
takes from the point the script issues the command up until the server is actually halted and apply this value,
maybe increased for a few seconds to be safe, to the UPS parameter I mentioned.
For 2. you can't do much but turn on the UPS manually. But IMO the overall shutdown procedure described in this bug report should be followed or else we won't have a clean shutdown at all, regardless of how the UPS turns back on.

#9 Updated by Cyber Jock over 5 years ago

So here's my comments/concerns. Note that all of this is based on personal experience and my own phone calls to APC because I had these problems with a UPS I bought from them. I had multiple problems with the UPS not behaving as expected, which took almost 2 full days to identify.

1. Some UPSes (namely home UPSes which sell themselves as "green") will use the previous power-off behavior to dictate the next shutdown behavior. So if in the previous shutdown you sent the command to shutdown the UPS, then the UPS will shut down the next time (but not subsequent times) based on that setting. This may or may not be desired (in my case, as well as many home users, this would be very unacceptable because the UPS will take initiative on its own to shutdown the UPS). So as soon as you go on the battery, and there is a "significant drop in load"* the UPS will trip a timer that will trigger the UPS to turn off. The timer seems to range from 15s to 5m depending on the model according to APC.
  • - APC would not tell me what the conditions were for the drop in load, but as I saw firsthand it is entirely possible to have the UPS decide to power itself off before the server has had enough time to shutdown properly.
    2. If you turn the UPS off, you must manually turn the UPS on before you can power on any devices on the server. (Note that if the UPS' battery goes dead, but later line power is restored, the UPS will default to on.) In this scenario it not only allows for the server to power itself on if the BIOS setting is set to poweron automatically, but it allows you to power on the server via IPMI. For my UPS at home I cannot ever have the servers power on automatically because the first thing that happens when the UPS comes on is a test of the voltage regulator. Due to the sudden load put on the UPS from even 1 machine (I have 3 on my UPS) the voltage regulator will not be able to maintain voltage from the initial surge and the UPS will trip offline on a failure of the voltage regulator to function. This creates even more problems that require someone to personally be onsite to fix this condition.
    3. Once the UPS has received the "poweroff" signal from the server, some UPSes (my friend's in particular) will power off even if line power is restored before the UPS actually turns off. This seems counter-intuitive because in one case we powered the FreeNAS server on and was working in the WebGUI when the server and UPS suddenly decided to turn power off (it turned out it hit its "threshold".

Anyway, to sum up everything I explained:

1. I understand the desire to have this feature in some scenarios.
2. There are plenty of situations where this feature really can't result in a good situation for many home users.
3. I think this feature really needs to be a checkbox that can be enabled (default disabled) and the FreeNAS manual needs to give a warning about potential problems and to test it in your environment and your UPS to ensure consistent (and desired) behavior before enabling long-term. I'd bet that many home users are not prepared (or aware) of the changes that can take place by enabling this feature and we should probably restore the previous behavior and allow people to enable it if they want it.

In my case, this removes the ability for myself and most of my friend's FreeNAS builds to actually power on the server remotely via IPMI without trying to find a UPS that doesn't have these problems (and if you search around the web you'll find we are far from alone as many have complained about this problem). In my case my network but not the servers are setup to turn on when power is restored and I can manually boot everything up via IPMI. There is no amount of workaround that I can do with my hardware to provide this function and as such I've rolled by my FreeNAS version on my main server as I must have this function when I travel. Otherwise on a loss of power I'd be unable to access anything on my network until I returned home.

@Josh Paetzel-

Do you want me to put in a feature request or do you want to make the changes this under the ticket?

#10 Updated by Jonathan Hankins over 5 years ago

FWIW, helped someone on IRC today that was bit by this change. Their UPS had other equipment on it that needed to stay up after the FreeNAS box shut down.

@Cyber Jock - did you ever ask for a "enable" checkbox enhancement as a separate ticket? If not, I think you're right, it's needed, along with the doc warning you mentioned.

#11 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Target version changed from Unspecified to N/A

Also available in: Atom PDF