From: riggor9999 on
On Oct 12, 2:13 pm, Günther Schwarz <st...(a)gmx.de> wrote:
> riggor9999 wrote:
> > So - when I specify duration of 300 using the example above, what
> > happens when the  power fails is that it takes one minute after the
> > power fails for the script to kick off.  The script kicks off, and the
> > shutdown command waits for 60 seconds max (not the 300 I specified), and
> > then proceeds to shutdown ... regardless if the specified script is
> > running or completed.
>
> Assuming that the "shutdown command" calls initd with "init 0": why not
> letting initd handle your database or whatever you want to terminate
> cleanly prior to halting the system? Configured correctly with sufficient
> timeouts init will wait for the application to terminate prior to moving
> on for the next process.
> It is has been mentioned previously that one has to distinguish between
> initiating the shutdown and finally cutting power. The latter is an
> internal function of the UPS and will depend on the size of the battery.
> If the hardware can not provide for sufficient time to do a clean
> shutdown it is not suitable for the application. As the battery degrades
> in use an undersized UPS will become even more problematic over time.
>
> Günther

Yes - I can use the vendor software to initiate the shutdown, and add
my shudown scripts to rc0 and rc6.

I will also be looking at NUT.
From: riggor9999 on
On Oct 12, 8:05 am, Marcel Bruinsma <m...(a)nomail.afraid.org> wrote:
> Am Montag, 12. Oktober 2009 13:17, riggor9999 a écrit :
>
> >  pwrstate -pwrfail -delay 60 -active on -cmd
> >    /etc/pwrstatd-powerfail.sh -duration 1 -shutdown on
>
> > The problem is the duration variable ... which can only be
> > between 0 and 60 seconds ... which is the length of time you
> > must specify the powerfail script (or any other script you
> > specify) will take to run before the system shuts down.
>
> As the command (-cmd ...) will run as root, perhaps it
> could suspend the daemon by sending it a STOP signal.
> When command is finished, it sends a CONT signal to
> the daemon. The duration would effectively become
> infinite.
>
> --
> printf -v email $(echo \ 155 141 162 143 145 154 142 162 165 151 \
> 156 163 155 141 100 171 141 150 157 157 056 143 157 155|tr \  \\\\)
> #  Live every life as if it were your last!  #

Creative approach - I will have to play with it / test it

From: Moe Trin on
On Sun, 11 Oct 2009, in the Usenet newsgroup alt.os.linux.suse, in article
<hattgi$g07$1(a)news.eternal-september.org>, riggor9999 wrote:

>"Moe Trin" <ibuprofin(a)painkiller.example.tld> wrote

>> Boy, you're sure supplying a lot of details here.
>>
>> 1. Which CyberPower UPS

>CP1500AVRLCD ... does that help?

We're primarily using APCs, but there are at least four CP1500 AVRs
(or the "Best Buy" equivalent GS-1500AVR which is a rebadged version
of the CP1500) in one of the server rooms. I'm not the UPS guy (I'm
running APCs at home), so I can't tell you how ours are run, but they
seem to be running NUT (http://www.networkupstools.org/)

>> 2. Which software?

>powerpanel-1.1.2-0.i386.rpm but it works with all their models ...
>does that help?

Never saw that before - this might be OK for stand-alones, the NUT
version is substantially more capable and better documented.

>> 3. Which "driver"

>It's conneted via USB - it seems both the powerpanel software and
>PowerManager 2.14 are using the native SUSE drivers ... does that help?

No - GNOME is not really designed for this (we don't waste CPU cycles
running fsckin' GUIs on our mostly headless servers).

>As I said in my original post the CyberPower powerpanel software is
>limited. It has to shutdown conditions ... low battery and powerfail.

which is fine - but the one minute maximum is not very well explained.

# How much time in seconds to take script running for event of Power
# Failure. The allowed range is 0 ~ 60. Default is 0 sec.
powerfail-duration = 0

and

# How much time in seconds to take script running for event of
# Battery Low. The allowed range is 0 ~ 60. Default is 0 sec.
lowbatt-duration = 0

Zero seconds to run scripts doesn't seem correct. Have you actually
dinked around with this on a test box? Normally, I'd expect one or
more timers started with a power failure (one to send mail to the
hell-desk in case they didn't notice the power fail, one to actually
initiate a shutdown), with the timer causing a script to run to shut
down userland stuff. AFTER that has occurred, I'd expect the system
to run the inittab 'pf' event to shut down the system, AND AS PART OF
THAT event, send a command to the UPS to shut down in N seconds
(giving time to finish the system shutdown). The documentation with
this program sucks mightily, and it's not clear exactly what these
various delays in the pwrstatd.conf file mean.

>BUT ... the problem is that the script can run for a max of one
>minute before powerpanel issues the shutdown command. I need 5
>minutes. As I said - I have a ticket open with the software vendor.

I would recommend looking at the NUT programs (nut-2.4.1 looks to be
the current version). For this program, you might look into running
your application shutdown script some amount of time after "powerfail"
and NOT shutting the system itself down,

# Allow Daemon to shutdown system for event of Power Failure.
# The allowed options are yes and no. Default is yes.
powerfail-shutdown = yes

(change that to 'powerfail-shutdown = no') and then running
'/sbin/shutdown -h now &' (or '/sbin/telinit 0' - your choice) at the
very end of your script. But what do these variables do?

# The necessary time in seconds for system shutdown.
# The UPS will turn power off when this time is expired.
# The allowed range is 0 ~ 3600. Default is 600 sec.(10 min.)
shutdown-sustain = 600

# Daemon will turn UPS power off once it ask system shutdown cause by
# a power event. Allowed options are yes and no. Default is yes.
turn-ups-off = yes

>I was looking for what others have done.

I suspect that most are running different software that doesn't have
this limitation, or at least has more understandable documentation.
(Yes, I realize that CyberPower Systems is in Taiwan, and English is
not a primary language there, but they _do_ have an office in
Shakopee - a Minneapolis suburb and ought to be able to find someone
who can write better.)

Old guy
From: riggor9999 on

"Moe Trin" <ibuprofin(a)painkiller.example.tld> wrote in message
news:slrnhd7k3p.5gd.ibuprofin(a)compton.phx.az.us...
> On Sun, 11 Oct 2009, in the Usenet newsgroup alt.os.linux.suse, in article
> <hattgi$g07$1(a)news.eternal-september.org>, riggor9999 wrote:
>
>>"Moe Trin" <ibuprofin(a)painkiller.example.tld> wrote
>
<SNIP>

The software is very simple and straight forward. Actions for power fail,
and actions for low battery. The actions include send email, run a script,
shutdown, turn off the ups, etc. The confirmed limitation is that the
program will only wait one minute max after kicking off an action script
before starting shutdown ... for both powerfail and low battery.

I called Cyber support in the US - they understood and agreed that the max
time allowed to run a script before starting the shutdown sequence is too
short / unrealistic and should be increased. I am surprised no one has
complained about this before.

I understand what you are saying. I had played / tested / changed config
with the PowerPanel software for powerfail and low battery ... and now
looking into NUT. I would prefer to use the PowerPanel software, as it is
designed for their UP and it has a very small footprint.

They have forwarded my detailed request to the Linux developer ... and they
expect to release an update in a week or two.

In the meantime - this is a technical sandbox at home - running two Oracle
databases with SAP. It is not mission critical ... but it is the season for
wind storms here and we lose power quite often. I am trying avoid having to
do restores in the event of physical or logical data corruption.

What I am now going to test is at powerfail - run the script but do not
shutdown the system, and at low battery - do not run the script - but go
ahead and shutdown. This should accomplish what I need.





From: Moe Trin on
On Tue, 13 Oct 2009, in the Usenet newsgroup alt.os.linux.suse, in article
<hb1veb$e7o$1(a)news.eternal-september.org>, riggor9999 wrote:

>I called Cyber support in the US - they understood and agreed that
>the max time allowed to run a script before starting the shutdown
>sequence is too short / unrealistic and should be increased. I am
>surprised no one has complained about this before.

As mentioned, this is the first time I've seen the program. The
software that has been available in the past doesn't seem to have
the problem. Based on the minimal capability of their program
(example, the lack of master/slave capability over the network[1]), I
suspect their products are more for the home user, where it would not
enocunter a database with eleventy-thousand files open, or similar.

>I would prefer to use the PowerPanel software, as it is designed for
>their UP and it has a very small footprint.

Smaller - yes, but other than that, I'm not sure what benefits it
offers over NUT and others where you actually get source code.

>In the meantime - this is a technical sandbox at home - running two
>Oracle databases with SAP. It is not mission critical ... but it is
>the season for wind storms here and we lose power quite often.

We get some freak thunderstorms once/twice a year that have been known
to blow down a half mile of powerline (microbursts exist!), and a lot
of the power distribution in residential areas is underground (partly
for that reason, partly for looks). Thus, our major problem is drunks
missing a turn (or making one when they shouldn't) and driving through
the surface mounted transformers. We get some momentary outages, but
normally when power fails for more than a few seconds, it's going to
be out for an hour or more.

>I am trying avoid having to do restores in the event of physical or
>logical data corruption.

Other than UPS and decent filesystem, the normal solution is RAID of
some kind, but most databases are not very tolerant of unplanned
shutdowns.

>What I am now going to test is at powerfail - run the script but do
>not shutdown the system, and at low battery - do not run the script -
>but go ahead and shutdown. This should accomplish what I need.

The concern I'd have about that (other than the deep discharge effects
on the batteries) is the (more or less) remote chance of consecutive
power outages leaving you with insufficient charge in the batteries
to do a clean shutdown the second or third time.

Old guy

[1] Master system has the UPS control cables, slave is merely powered
by the same UPS, and receives a shutdown command (if needed) over the
network. At home, eight systems are running off 3 UPS.