> 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
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?
>>
>>
> 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
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.
>
>
> > 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
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
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
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
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
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
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
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
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
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 -
14 matches
Mail list logo