No subject

charge, but instead will be raised a few seconds before the power will
be cut by the UPS, either because of a low battery event or a user
initiated shutdown (with delay) command. The thing I don't like about
that, is that by that time the shutdown sequence has apparently already
started by the UPS, which means that we have no control over when the
power will be cut.

Also, if it indeed only pops up just a few seconds before loss of power,
this is well below the time needed it will take the server and clients
(in addition to the server, up to 5 seconds) to pickup on this and *way*
too short to initiate a clean shutdown procedure anyway. It might be
useful for logging remote UPS'es, so it might be worth logging by
'upslog', that's why I didn't outright remove it.

In a normal situation, NUT won't wait until ShutdownImminent is
signaled, rather it will initiate a shutdown sequence as soon as
BelowRemainingCapacityLimit or RemainingTimeLimitExpired is set. As soon
as we have found that (and we have OB LB), it is irrelevant what the UPS
sends, since there is no way to stop (or speedup) a shutdown sequence
from that moment on.

> Other cases are handled by
> the hardware through the BYPASS (overload), the RB (replace battery or
> internal failure). It has also saved some users life by "launching" the
> shutdown sequence.

That last comment puzzles me. How do you know that? :-) What you're
basically telling, is that there are UPS'es out there that support
neither BelowRemainingCapacityLimit nor RemainingTimeLimitExpired,
right? That sucks...

> I've even thought about allowing the FSD setting (or an equivalence) by the driver to force emergency stop.

That would be *very* bad. That would mean that if a user signals a UPS
to go down (shutdown with delay), it would bring down all UPS'es (and
systems) connected to that same server. We even warn for this in the
documentation:

	Note: upsd injects "FSD" by itself following that command by a
	master upsmon process.  Drivers must not set that value.

> Since we (MGE) don't use the RemainingTimeLimitExpired nor
> FullyDischarged, I can't tell for these ones. But in theory, the
> FullyDischarged flag should also trigger LB.

I discussed this with Peter and we came to the conclusion that
Fully(Dis)Charged indicates the end of (dis)charge and as such should
remove the (DIS)CHRG flag from "ups.status". By that time the battery
charge indication will be well below the level where LB will be
triggered, so adding this will add no additional value here. After all,
if a client wouldn't respond to signals that the battery is getting low
(all subdrivers seem to support that), why would it care now?

RemainingTimeLimitExpired is a different matter. That is equivalent to
BelowRemainingCapacityLimit (only now looking at time remaining, instead
of charge remaining) so that needs to be mapped to LB as well (changing
that was a mistake). I will change this back.

Best regards, Arjen