Re: [Nut-upsuser] UPS Shutdown
> But at this point, the shutdown delay, as executed by a real, live, existing > UPS, seems to be an unattainable fantasy to this mere, simple user. > > > > Something as critical as the shutdown delay should be so supremely documented > that it is child's play. > > But it is not. It currently is wizardry, if it exists at all. I've been able to get delayed UPS shutdown working easily and reliably, using upscmd: upscmd -u username -p password ups load.off.delay 300 Note that this doesn't tell the UPS to turn back on when the power restores. Thanks, Jeff Bowman Fairbanks, Alaska ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS Shutdown
On 10/5/2016 10:59 PM, Jeff Bowman wrote: > >>> How does this work in conjunction with the UPS hardware? Does NUT >>> immediately send a command to the UPS to wait for 300 seconds and then >>> shut itself down, thereby allowing the server enough time to safely >>> shut itself down as well? >> >> Yes. > > Very good, thank you. > > > >> The command is "upsdrvctl shutdown". > > That's what I thought, but I get this: > > Can't claim USB device [051d:0003]: libusb0-dll:err [claim_interface] could > not > claim interface 0, win error: The requested resource is in use. > > Driver failed to start (exit status=1) > [snip] I have found the shutdown delay to be quite elusive within the NUT realm. I have asked for the kind folk of this mailing list to post those UPS's which actually can implement the shutdown delay concept. I have not seen anything posted, here or on the website, to that effect. Nor have I seen any manner of documentation in the various UPS profiles that would suggest whether or not a specific UPS actually obeys and complies with the shutdown delay concept. I use NUT and I like NUT, and I sincerely appreciate all the effort put into making this project happen. Really. But at this point, the shutdown delay, as executed by a real, live, existing UPS, seems to be an unattainable fantasy to this mere, simple user. Something as critical as the shutdown delay should be so supremely documented that it is child's play. But it is not. It currently is wizardry, if it exists at all. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS Shutdown
> The "upsdrvctl shutdown" command is designed to be run late in the shutdown > sequence, and has to be run after the rest of NUT (drivers, upsd, etc) has > been stopped. It does, in fact, restart the driver with the "-k" option to > kill the UPS rather than monitor it. (If I understand Roger's diagram, > systemd invokes the "upsdrvctl shutdown" after most of the other processes > have been stopped.) OK, I see. > There are also ways to send shutdown commands to a running driver with > "upscmd", which is useful for scenarios other than "shutdown and return when > the power returns". > > http://networkupstools.org/docs/man/upscmd.html I think that's going to be what I'm looking for. Thanks, Jeff Bowman Fairbanks, Alaska ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS Shutdown
On Oct 5, 2016, at 10:59 PM, Jeff Bowman wrote:
>
>> The command is "upsdrvctl shutdown".
>
> That's what I thought, but I get this:
>
> Can't claim USB device [051d:0003]: libusb0-dll:err [claim_interface] could
> not
> claim interface 0, win error: The requested resource is in use.
>
> Driver failed to start (exit status=1)
>
> I don't know why it thinks I'm trying to start the driver.
>
The "upsdrvctl shutdown" command is designed to be run late in the shutdown
sequence, and has to be run after the rest of NUT (drivers, upsd, etc) has been
stopped. It does, in fact, restart the driver with the "-k" option to kill the
UPS rather than monitor it. (If I understand Roger's diagram, systemd invokes
the "upsdrvctl shutdown" after most of the other processes have been stopped.)
There are also ways to send shutdown commands to a running driver with
"upscmd", which is useful for scenarios other than "shutdown and return when
the power returns".
http://networkupstools.org/docs/man/upscmd.html
http://networkupstools.org/docs/user-manual.chunked/apcs02.html ("Instant
commands")
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS Shutdown
> > How does this work in conjunction with the UPS hardware? Does NUT > > immediately send a command to the UPS to wait for 300 seconds and then > > shut itself down, thereby allowing the server enough time to safely > > shut itself down as well? > > Yes. Very good, thank you. > The command is "upsdrvctl shutdown". That's what I thought, but I get this: Can't claim USB device [051d:0003]: libusb0-dll:err [claim_interface] could not claim interface 0, win error: The requested resource is in use. Driver failed to start (exit status=1) I don't know why it thinks I'm trying to start the driver. > The 300 seconds start when the effect of "upsdrvctl shutdown" reaches the UPS > hardware. See the diagrams at http://rogerprice.org/NUT.html#SYSD_RACE which > assume an offdelay of 20 seconds. That's what I was hoping for. Thank you for the helpful diagram. I also am not able to get the script specified in NOTIFYCMD to run when NOTIFYFLAG ONBATT EXEC is encountered. At this point, being pressed for time, it looks like I'm going to have to settle for writing a Windows Service that polls the output of [upsc ups@localhost ups.status] and responds accordingly. That should get me by for now. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS Shutdown
On Wed, 5 Oct 2016, Jeff Bowman wrote: I’m trying to better understand OffDelay and OnDelay: http://networkupstools.org/docs/man/usbhid-ups.html#_extra_arguments My server requires ~3½ minutes to shut itself down. Considering this I’m comfortable setting OffDelay to 300 (five minutes). How does this work in conjunction with the UPS hardware? Does NUT immediately send a command to the UPS to wait for 300 seconds and then shut itself down, thereby allowing the server enough time to safely shut itself down as well? Yes. This is the only way I can think of that the arrangement can work. As it’s naturally impossible for a turned-off computer to send any command anywhere, an option for sending a “take-this-now-but act-on-it-later” command surely must exist. The command is "upsdrvctl shutdown". I’ll be initiating my own shutdown sequence as a result of NOTIFYCMD with a NOTIFYTYPE of ONBATT. My process will poll battery status for five minutes (to reduce false positives) before finally deciding to send individual shutdown commands to the server, NAS, other devices, etc. In other words, I’m going to write my own upssched, suited specifically to my platform and configuration needs. Given this configuration, at what point will the 300 seconds start counting down? What trigger sends the actual command which in turn tells the UPS hardware to start that countdown? The documentation is unclear on this finer point. The 300 seconds start when the effect of "upsdrvctl shutdown" reaches the UPS hardware. See the diagrams at http://rogerprice.org/NUT.html#SYSD_RACE which assume an offdelay of 20 seconds. Roger___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] UPS Shutdown
I'm trying to better understand OffDelay and OnDelay: http://networkupstools.org/docs/man/usbhid-ups.html#_extra_arguments My server requires ~3½ minutes to shut itself down. Considering this I'm comfortable setting OffDelay to 300 (five minutes). How does this work in conjunction with the UPS hardware? Does NUT immediately send a command to the UPS to wait for 300 seconds and then shut itself down, thereby allowing the server enough time to safely shut itself down as well? This is the only way I can think of that the arrangement can work. As it's naturally impossible for a turned-off computer to send any command anywhere, an option for sending a "take-this-now-but act-on-it-later" command surely must exist. I'll be initiating my own shutdown sequence as a result of NOTIFYCMD with a NOTIFYTYPE of ONBATT. My process will poll battery status for five minutes (to reduce false positives) before finally deciding to send individual shutdown commands to the server, NAS, other devices, etc. In other words, I'm going to write my own upssched, suited specifically to my platform and configuration needs. Given this configuration, at what point will the 300 seconds start counting down? What trigger sends the actual command which in turn tells the UPS hardware to start that countdown? The documentation is unclear on this finer point. Thanks, Jeff Bowman Fairbanks, Alaska ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS shutdown - always the thing to do?
On Tue, Nov 20, 2007 at 09:31:59AM +0100, Arjen de Korte wrote: The best answer we can offer here, is to just try it out on your specific kind of hardware. The proof of the pudding is in the eating. Of course. The shortcoming being that running the UPS down that far would take a few hours - at which point I start thinking asking around might be more efficient use of time, just in case somebody knows, since really proving the pudding might take multiple cycles of full discharge-recharge, plus it's production equipment hanging on it I don't want to keep shutting down. The documentation does cover this. See 'docs/shutdown.txt' which describes exactly the problem you're picturing (under 'Power races') and also shows a way how to test if you're vulnerable to this kind of problem (under 'Testing power races'). Thanks. I was assuming the fullest docs were also on the Website; guess not. To another reply - it's the cyberpower driver that works with the 1500AVR. (The more modern driver skews the values badly. I requested the right conversions from the manufacturer, but the rep who responded regretted that he couldn't get the tech staff to reveal those.) Am I right that on average, presuming a professional-level UPS (this sucker at least is a rack-mount with a few hours of battery in it), and with PCs with bioses which will can be set to boot on any fresh power application, that I'm better off without sending shutdown to the UPS? Whit ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS shutdown - always the thing to do?
The best answer we can offer here, is to just try it out on your specific kind of hardware. The proof of the pudding is in the eating. Of course. The shortcoming being that running the UPS down that far would take a few hours - at which point I start thinking asking around might be more efficient use of time, just in case somebody knows, since really proving the pudding might take multiple cycles of full discharge-recharge, plus it's production equipment hanging on it I don't want to keep shutting down. It is not needed to run the batteries to empty. In order to try this out, you can 'fake' an OB+LB situation by issuing the 'upsmon -c fsd' command (this is also documented in 'docs/shutdown.txt' and the manual page for upsmon). Once with the mains present (to test a power race) and once without (to make sure the UPS doesn't restart on battery). If both of these are passed, it is still a good idea to run the UPS on battery until it signals OB+LB by itself. Sometimes the remaining time on battery is too short for an orderly shutdown of your systems and you certainly don't want to be surprised by that when you're not around. [...] To another reply - it's the cyberpower driver that works with the 1500AVR. (The more modern driver skews the values badly. I requested the right conversions from the manufacturer, but the rep who responded regretted that he couldn't get the tech staff to reveal those.) We already have (more or less) the conversion values that are needed. Problem is that we don't know when to apply these, as some devices seem to need them, while others don't. You could help us here by posting the full output of 'upsc' for your UPS. Am I right that on average, presuming a professional-level UPS (this sucker at least is a rack-mount with a few hours of battery in it), and with PCs with bioses which will can be set to boot on any fresh power application, that I'm better off without sending shutdown to the UPS? Not at all. In that case, you'd be vulnerable to power races (see the aforementioned document). This has really nothing to do with the BIOS in the PC, but rather with the fact that once we initiate a shutdown sequence in NUT, there is no way back anymore. As soon as the shutdown sequence is started, the only way to resume normal operation is to reboot the machine. This is what the shutdown command will do. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS shutdown - always the thing to do?
On 11/19/07 18:28, Whit Blauvelt wrote: Now looking at the FAQ again, it offers the same snippet of code as the Install doc, but implies that it isn't needed just in case the bios - as mine does - has an always power on when power's restored option. I don't see how that will help... If that implication is right, then does that mean that soon after the UPS gives the signal to the PC that the PC should consider shutting down, that the UPS will cut the power anyway - assuring a power cycle to restart the PC? That is not my experience. However, I think there are some UPSs out there that will kill the power to the PC automatically after some delay. From my testing, the CyberPower AVR1200 that I use does not do this. If so, that could leave a small window between the PC's going off and the UPS cutting the power (when not commanded to do so prematurely with that shutdown command) in which power restoration wouldn't trigger the PC rebooting - unless the UPS is smart enough to power cycle on power restoration just in the case that it was past the point of advising PC shutdowns already. If that's so, then I should stop worrying and get back to packing for vacation. I think to make this work, you're going to have to tell the UPS to kill the power to the PC. Without that, you don't have any way to tell the PC to boot back up (unless, of course, the UPS battery goes dead before the line power is restored - I don't want to depend on that). (I'm not, btw, really expecting you know this level of detail - just figuring someone on this list probably does. The docs seem to not quite cover this.) Well, as I've said, I'm not an expert. I've just recently gone through this with a CyberPower AVR1200 connected to a CentOS 4.5 (RedHat Enterprise Linux) system. Good luck. Regards, Whit -- Mark Hansen, PP-ASEL, Instrument Airplane, USUA Ultralight Pilot Cal Aggie Flying Farmers Sacramento, CA ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS shutdown - always the thing to do?
On 11/19/07 12:46, Whit Blauvelt wrote: Hi, In an instance where the system is in a sometimes-unattended facility, are there different implications to shutting down the UPS from a script, as compared to not doing so? My goal is to have systems recover ASAP when the power comes back. My UPS is a Cyberpower 1500AVR. The two servers connected to it boot fine when power is restored to them. But I'm ignorant on how the UPS itself will behave. If shut down, do UPS's as a rule turn on when power comes back? Or does that depend on the model? Is there an argument for not shutting the UPS down, just in case power comes back before it's run out of battery even to sustain even its own state? Thanks, Whit I'm not a UPS expert (or NUT for that matter), but just went through all this with my CyberPower AVR1200 connected to a Linux machine. First, I assume that you have the NUT package configured such that when the line power fails, the UPS will cause the PC to shutdown. If you allow the PC to shut all the way down, then it likely won't boot back up when the line power returns. What you need to do is to tell the UPS to kill the power to the PC just before the machine completes the shutdown sequence. This way, your machine's shutdown scripts will be able to do everything they need to do, like kill all the applications, sync the drives, etc., and then tell the UPS to kill the power to the PC. Because the PC's shutdown script tells the UPS to kill the power to the PC, the PC's BIOS thinks the PC was up when it's power failed. Then, once line power is returned to the UPS, it will restore power to the PC, and the PC will boot up as usual. Unfortunately in my case (CentOS 4.5) I had to do a fair amount of twiddling with my machine's shutdown script (/etc/init.d/halt) to get it to do this. It certainly didn't work out of the box. Let me know if you have any questions, as I may not have understood your request. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS shutdown - always the thing to do?
Mark, Thanks. That helps clarify my question. Okay, so Nut picks up the signal from the UPS that it's time to shut down the PC. The PC does its shutdown, and then from the Nut install doc You should configure your system to power down the UPS after the filesystems are remounted read-only. What you're suggesting is that the shutdown command to the UPS is really not telling the UPS to power down itself, but to power down the PC? Because I was taking that literally as telling the UPS to power itself down. That's why I was asking if the UPS by default would power itself back up. Because I don't recall that just plugging it in is enough to turn it on - there's that button on it that needs pressing. But if the shutdown command to the UPS really means cut power to the PC, but stay on yourself on the rest of your residual power (or come back on when wall power comes back) - well that's a very different scenario. My PC bios has the option enabled to turn on on power restoration, no matter what the state was when power was turned off. Even so, if they shut themselves down, but then don't see the power cycled from the UPS end, that would be a problem. So does that /usr/local/ups/bin/upsdrvctl shutdown command really tell the UPS power down the output, but only until power's back at the wall, then repower? That is, it's not just telling the UPS to turn itself off, awaiting a human finger go to on again? Best, Whit On Mon, Nov 19, 2007 at 01:07:59PM -0800, Mark E. Hansen wrote: On 11/19/07 12:46, Whit Blauvelt wrote: Hi, In an instance where the system is in a sometimes-unattended facility, are there different implications to shutting down the UPS from a script, as compared to not doing so? My goal is to have systems recover ASAP when the power comes back. My UPS is a Cyberpower 1500AVR. The two servers connected to it boot fine when power is restored to them. But I'm ignorant on how the UPS itself will behave. If shut down, do UPS's as a rule turn on when power comes back? Or does that depend on the model? Is there an argument for not shutting the UPS down, just in case power comes back before it's run out of battery even to sustain even its own state? Thanks, Whit I'm not a UPS expert (or NUT for that matter), but just went through all this with my CyberPower AVR1200 connected to a Linux machine. First, I assume that you have the NUT package configured such that when the line power fails, the UPS will cause the PC to shutdown. If you allow the PC to shut all the way down, then it likely won't boot back up when the line power returns. What you need to do is to tell the UPS to kill the power to the PC just before the machine completes the shutdown sequence. This way, your machine's shutdown scripts will be able to do everything they need to do, like kill all the applications, sync the drives, etc., and then tell the UPS to kill the power to the PC. Because the PC's shutdown script tells the UPS to kill the power to the PC, the PC's BIOS thinks the PC was up when it's power failed. Then, once line power is returned to the UPS, it will restore power to the PC, and the PC will boot up as usual. Unfortunately in my case (CentOS 4.5) I had to do a fair amount of twiddling with my machine's shutdown script (/etc/init.d/halt) to get it to do this. It certainly didn't work out of the box. Let me know if you have any questions, as I may not have understood your request. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS shutdown - always the thing to do?
Now looking at the FAQ again, it offers the same snippet of code as the Install doc, but implies that it isn't needed just in case the bios - as mine does - has an always power on when power's restored option. If that implication is right, then does that mean that soon after the UPS gives the signal to the PC that the PC should consider shutting down, that the UPS will cut the power anyway - assuring a power cycle to restart the PC? If so, that could leave a small window between the PC's going off and the UPS cutting the power (when not commanded to do so prematurely with that shutdown command) in which power restoration wouldn't trigger the PC rebooting - unless the UPS is smart enough to power cycle on power restoration just in the case that it was past the point of advising PC shutdowns already. If that's so, then I should stop worrying and get back to packing for vacation. (I'm not, btw, really expecting you know this level of detail - just figuring someone on this list probably does. The docs seem to not quite cover this.) Regards, Whit ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS shutdown - always the thing to do?
On Nov 19, 2007 9:28 PM, Whit Blauvelt [EMAIL PROTECTED] wrote: If so, that could leave a small window between the PC's going off and the UPS cutting the power (when not commanded to do so prematurely with that shutdown command) in which power restoration wouldn't trigger the PC rebooting - unless the UPS is smart enough to power cycle on power restoration just in the case that it was past the point of advising PC shutdowns already. If that's so, then I should stop worrying and get back to packing for vacation. Generally speaking, when the UPS signals on battery + low battery, and the driver passes this back to NUT, the modified shutdown scripts need to tell the UPS to pull power _after a delay_. That delay is where the race condition can occur, and higher-end UPSes are designed to cycle the output power even if the input power returns during that window. The shutdown command to the UPS is considered a point of no return, in that case. I can't speak specifically to the 1500AVR, but if the UPS is just designed to provide a bit of backup power to shutdown a desktop machine, it may not have all of the bells and whistles like power-cycling the output after a shutdown+delay command. -- - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
