Nut upsuser - Apr 2008 - NUT 2.0.4-4 - Debian stable - /etc/killpower not created?

Hello....

I'm testing the functionality of my NUT-setup (NUT 2.0.4-4 - Debian 
stable). The system is connected to the UPS, but is not powered by it.

When running "upsmon -c fsd", upsmon says "Auto logout and
shutdown
proceeding". This is all well and good, but I never see the machine 
waiting for the UPS to cut the power. Instead it shuts down.

It's my understanding that upsmon should create /etc/killpower, report 
this found in the syslog, and then wait for the power to be cut.

Maybe I have misunderstood something?

Thanks,
Tobias

On Tue, Apr 29, 2008 at 1:32 PM, Tobias Balle-Petersen
<tbp at kontrapunkt.com> wrote:
>  Maybe I have misunderstood something?
"upsmon -c fsd" triggers an automatic shudown, just like when the UPS
is low on battery and there's no line power. At the end of the
shutdown process, the box checks for /etc/killpower and, if it finds
it, sends a signal to the UPS telling it to power off and then shuts
down (if the UPS doesn't power off immediately - usually, the UPS
waits a few seconds before powering itself off).


-- 
Carlos Rodrigues

> I'm testing the functionality of my NUT-setup (NUT 2.0.4-4 - Debian
> stable). The system is connected to the UPS, but is not powered by it.
Good idea when you're testing your setup.
> When running "upsmon -c fsd", upsmon says "Auto logout and
shutdown
> proceeding". This is all well and good, but I never see the machine
> waiting for the UPS to cut the power. Instead it shuts down.
>
> It's my understanding that upsmon should create /etc/killpower, report
> this found in the syslog, and then wait for the power to be cut.
>
> Maybe I have misunderstood something?
You have. NUT will indeed create this flag and provided you've made the
necessary changes in your system 'halt' script, this in turn will call
'upsdrvctl shutdown'. Depending on the driver you're using, the
actual
shutdown of the UPS may take next to no time at all or up to a minute (or
more) to happen. In the mean time, it is a good idea to not hang around in
the halt script, but to power-off the system in the normal way. The reason
for doing so, is that not all hardware will shutdown without problems if
the power is suddenly cut, even if you've sync'ed your filesystems
and/or
(re)mounted them read-only. Therefor, the default behaviour for most
drivers is to shutdown the UPS with a delay to allow the halt script to do
its thing.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57

Please keep the mailinglist posted.
> I was under the impression that the ability of the machine to restart on
> return of power depended on the power beeing cut while the system is
> running. Is that not how it works?
That depends on your system. Some will 'remember' the last status before
the power is cut, others will startup on the application of power.
> I have run my master and slave powered by the ups. I have let the ups
> run dry. The machines shut down as expected. They restart when ups is
> given power again. So it looks okay.
Yes.
> My real question is:
> How can I make sure that a machine was "ready" when the power was
cut? I
> have been getting messages about corrupt databases on return from a
> power out.
The latter could happen, if the shutdown sequence of a slave takes longer
than that of the master. In that case, the slave may not have finished
shutting down at the time the power is cut. How to work around this, is
documented in the FAQ and the docs/shutdown.txt document. The only way to
prevent something like this happening upfront, is to have a dedicated UPS
for every system. Having said that, increasing FINALDELAY on the master
usually will give satisfactory results too (but don't overdo this, or else
you risk that the master will be hit by a sudden power cut if the battery
of the UPS is depleted). Alternatively, you could increase the
'offdelay'
time on your UPS (if the driver supports this), but this will have
drawbacks too.

Best regards, Arjen

Please keep the mailinglist posted. I won't reply to messages sent to me 
in private, unless a consulting fee is involved.
>>> How can I make sure that a machine was "ready" when the
power was
>>> cut? I
>>> have been getting messages about corrupt databases on return from a
>>> power out.
>>
>> The latter could happen, if the shutdown sequence of a slave takes 
>> longer
>> than that of the master. In that case, the slave may not have finished
>> shutting down at the time the power is cut.
>
> This happens on the master.
In that case either you're sending the shutdown command to the UPS at 
the wrong time (it should be near the bottom of the halt script, just 
before the system power-off command) or your database doesn't respond to 
a SIGTERM signal in a timely matter (it doesn't have enough time to 
proceed and it receives a SIGKILL before it has
finished).
>
> In my halt script, it looks for /etc/killpower. It should log if this 
> file exists or not. However, I never see anything like this in my 
> logs.  What could the reason be?
It can't. At the time you're looking for this file, the syslogd
won't be
running anymore, so you can't write to the logs anymore. This is normal.

Best regards, Arjen

Please keep the mailinglist posted.
> If I shutdown with "upsmon -c fsd" the databases are shut down
> correctly.
That is bad. It means that the system shutdown sequence takes longer than
the remaining runtime on batteries after reporting 'battery low'. In
other
words, the UPS is powering off because of depleted batteries, rather than
by receiving a power-off signal. The filesystems may not be ready for loss
of power (ie, have not been sync'ed and/or remounter R/O).

Depending on the UPS you're using, you should either increase the battery
level when a low battery warning is indicated or use 'upssched' to
shutdown after a fixed time after loss of mains power.

Best regards, Arjen