Nut and RAID on FreeBSD 7.0

[Derek Ragona]

At 04:43 PM 1/10/2008, Derrick Ryalls wrote:
> > >
> >  > Greetings,
> >  >
> >  >  I have a RAID fileserver plugged into a UPS and nut is able to
> >  >  communicate with it successfully.  With the winds making the lights
> >  >  flicker, I started looking into having the computer shut down when
> >  >  power goes out for more than say 5 minutes or so.  Looking at the
> >  >  documentation, I found that the 'true' solution is more like the
> >  >  system goes into a safe state when the battery gets low, then the ups
> >  >  eventually dies.  When power is restored, the UPS and computer are
> >  >  supposed to both come back to life.  This would be a great system to
> >  >  have in place, but it does sound a bit risky and so may not be worth
> >  >  doing just to save my home fileserver.
> >  >
> >  >  The instructions and the conf file have the shutdown command of
> >  >  'shutdown -h +0' which will halt the system.  The man page for halt
> >  >  says the the disk cache will be flushed, but doesn't mention anything
> >  >  about going to read-only or anything.  I suppose my first question is
> >  >  whether or not flushing the cache is sufficient to save the RAID (5)
> >  >  array, or if I need to find a way to get the file systems into read
> >  >  only mode?
> >  >
> >  >  The second question has to do with a rc.d script that nut recommends
> >  >  creating.  The script does a 'upsdrvctl shutdown' and then a sleep
> >  >  120, basically waiting for the machine to die while in the script.
> >  >  Won't this block the other rc.d scripts?  Also, is this the magic part
> >  >  that enables the machine to auto power up when power is restored?
> >  >
> >  >  Changing the shutdown command in nut to 'shutdown -p +0' looks like
> >  >  the sure fire way to get the system down clean before the power is
> >  >  lost, but if my concerns are not valid, then I could be missing out on
> >  >  some nice functionality for no reason.
> >  >
> >  >  Does anyone have experience with this?
> >  >  I have my servers all using nut to safely shutdown.  My 
> configuration is
> >  > the servers are set up with one as master for nut, that master connected
> > to
> >  > the UPS.  The other servers are slaves and get their nut information 
> from
> >  > the master.
> >  >
> >  >  My setup has the servers wait until the UPS is on low battery, then 
> they
> >  > all shutdown.
> >  >
> >  >  As a separate part of the setup, the servers are set in their BIOS to
> > power
> >  > on, after a power failure.  This is in the BIOS power setup.
> >  >
> >  >  So if there is a minor power problem, the servers run from battery.  In
> > a
> >  > larger power outage, they are shutdown cleanly once the battery level is
> >  > low, and power up automatically once power is restored.
> >  >
> >  >  In my upsmon.conf file I have this:
> >  >  SHUTDOWNCMD "/sbin/shutdown -h +0"
> >  >
> >  >  If you want more specifics, I can look through the configuration files
> > and
> >  > email you relevant settings.
> >  >
> >
> >  After doing more reading, I am confident that a shutdown -h would be
> >  sufficient, but am a bit concern on the order of operations.  The nut
> >  documentation has a recommendation to add a kill script as such:
> >
> >
> >  #!/bin/sh
> >
> >  if [ "$1" == "stop" ]
> >  then
> >
> >          if [ -f /etc/killpower ]
> >          then
> >                  echo "Killing the power, bye!"
> >                 /usr/local/libexec/nut/upsdrvctl shutdown
> >
> >                  sleep 120
> >          fi
> >  fi
> >
> >  </copy>
> >
> >  Even if I name this zz_killpower.sh to make it run last, depending on
> >  how long it takes FreeBSD to flush the cash after all rc.d scripts are
> >  run, I could end up doing a dirty power down, right?  Without this, if
> >  the power does come back while before the battery finally dies, the
> >  system won't restart since the power was never fully interrupted at
> >  the computer side?
> >  You are reading the old documentation.  The current nut, 2.2, has complete
> > rc scripts that are installed in /usr/local/etc/rc.d
> >
> >  You need only define the flag file you want to use in upsmon.conf
> >
> >  Also define what actions you want in that file as well.  You need to use
> > the sample files installed in /usr/local/etc/nut and be sure to read the
> > comments.
> >
>
>I have 2.2 installed and am using the existing scripts.  In the
>comments in uspmon.conf, there is this part:
>
># --------------------------------------------------------------------------
># POWERDOWNFLAG - Flag file for forcing UPS shutdown on the master system
>#
># upsmon will create a file with this name in master mode when it's time
># to shut down the load.  You should check for this file's existence in
># your shutdown scripts and run 'upsdrvctl shutdown' if it exists.
>#
># See the shutdown.txt file in the docs subdirectory for more information.
>
>POWERDOWNFLAG /etc/killpower
>
>Which in the related documentation means I need the custom shutdown
>script mentioned above which checks for the existence of the
>/etc/killpower file before doing the upsdrvctl shutdown command to
>kill the UPS before the battery is completely dead.  I suppose in your
>situation you won't need this extra script as you run until the UPS is
>critical whereas I am trying to kill the system a bit early, before it
>is critical.
>
>Perhaps I need to re-evaluate my line of thinking.  Light sometime
>flicker, but power almost never goes out.  When it does it is either
>back on in less than 1 minute, or out for hours.  If the UPS detects
>critical correctly and gives me at least a minute before death, then
>that should be plenty of time for the system to auto-shutdown.  Guess
>I will have to do some experimentation tonight.

Also, the first thing that starts to go bad on a UPS is the 
batterylife.  So just shutting down on low battery works well.  In my case, 
I don't worry about the UPS, it is so low on power by then it just chirps 
for another minute or so then it dies, completely exhausted.

         -Derek

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.