APC UPS - Not powering server down properly

[pek1973]

Hi Guys,

 

I have a APC UPS hooked up to my server, and have successfully installed the package, and its showing in unmenu correctly.  We had a poweroutage the other day while I was away and for some reason it appears that the server didn't powerdown correctly, so it automatically started a parity check upon reboot.  I did read the 3 page post covering this but with little luck.  My questions are:

 

1)  currently the UPS is set for 3 minutes or 5% battery remaining which is default - is there any way of changign this to 10% & 6 minutes just to play it safe?

2)  The server not powering down properly - how do i check that all the necessary files are installed to allow the server to shut down correctly when it see's the UPS hit its " triggered" levels?

3) I can't help thinking that I may have butchered something while trying to get the UPS program installed - I had a shocker with unmenu for some reason.

 

Have attached my syslog & my go file if someone could shed some light it would be appreciated:

 

#!/bin/bash

# Start the Management Utility

/usr/local/sbin/emhttp &

/boot/unmenu/uu

CTRLALTDEL=YES LOGSAVE=30

sysctl -w kernel.poweroff_cmd="/sbin/powerdown"

cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c

 

 

thx Paul

[Biggy2872]

Check out this thread.  it's long but has a lot of information.  You will need to add/edit the sed commands in the apcupsd unmenu package and then disable and re-enable the package for auto-install after the changes have been made.

 

http://lime-technology.com/forum/index.php?topic=1528.0

 

Cheers,

Matt

 

ps there may be other threads with information about modifying your apcupsd install for your specific needs.  A quick search of the forum should provide you with the needed information.

 

[RobJ]

I checked your syslog and it looks normal.  In particular, the APC stuff looks fine, so I can't help with that.

 

I noticed something else though that was unexpected, at least for me.  You have 6 drives, with a SiI3132 addon card controlling first a Seagate 1.5TB drive, then a Seagate 1TB drive with a Gigabyte HPA.  Then your parity drive (a WD 2TB drive) is connected to the first onboard SATA port, then there are 3 more Seagate 1TB drives connected to additional onboard ports.  You only have one drive with a Gigabyte HPA, and it is on the drive on the second port of the addon card!  Here is the advice I have been giving, my current thinking about this HPA, and it obviously conflicts with your setup.  The 3 explanations I can think of, are (1) that I am wrong that it only checks onboard ports, or (2) you found a way to disable this Gigabyte BIOS backup, HPA creating feature (and the existing HPA is from before you disabled it), or (3) this Gigabyte board is older than this HPA-creating feature (and the drive with HPA was once in another Gigabyte-based computer).  I would like to hear your comments on this, so I can correct my advice and thinking.  I think it still may be wise to reconnect your parity drive to a later onboard port.

 

I also noticed that you had the Seagate 1.5TB drive (a fast drive) on the Silicon Image addon card.  Recently, it has been brought to our attention that the commonly used Silicon Image chipsets have a UDMA/100 upper limit, which may limit the speed of the newest and fastest drives.  Seagates had that same limit until recently, because no drive needed to be faster than that, but with the fast new drives out, Seagate has raised their limit to UDMA/133, like the rest of the industry.  Your Seagate 1.5TB drive is one of the fastest, so it may be wise to move it to an onboard port, to avoid being artificially limited by the card's speed limit.  If you have time though, it would be very useful to test its current speed, as well as its speed when connected to an onboard port.  Use the following command at the console:

 

  hdparm -tT /dev/sda

 

The sda will change to something else when you reconnect it to an onboard port.  The only number you want is the very last one, ignore the rest.

 

I would like to confirm whether the speed when attached to the card is limited to under 100MB/s.  The User Benchmarks page, Hard Drive Read Speeds section already seems to confirm this slowdown.  If further confirmed, we should add appropriate comments to the Improving unRAID Performance page.

[pek1973]

Joe,

 

thanks for the reply, I'll run those tests and post the results.  I'll be a bit slow as I have a hectic few days ahead before i can respond.  Moving the parity drive should just be a case of rejigging the cables and then reassigning the drives accordingly in the setup page upon startup?

 

BTW, I read somewhere in my UPS researching travels that you can change the % / time that the server triggers a shutdown by editing the CONF file.  I've successfully got a windows machine monitoring the Server UPS (the WIN machine uses a dumb UPS) and have configured that to 30% or 10 minutes.  I would like to trigger the server to start shutdown at 25% or 7 minutes just to be on the safe side in regards to battery quality - ie. 3 min / 5% is fine when battery is new but a pretty short time to shutdown when the battery fatigues quickly near the end of its life.  I haven't had any luck getting the unraid server to reflect the required changes.  Any thing I'm doing wrong?  attached is the conf file.

 

thx, Paul

[Joe L.]

I haven't had any luck getting the unraid server to reflect the required changes.  Any thing I'm doing wrong?  attached is the conf file.

 

thx, Paul

Paul,

 

You were doing two things wrong.

 

1. You were editing the unMENU .conf file, but not in a way that would allow it to modify the apcupsd.conf file in /etc/apcupsd/apcupsd.conf .  The lines you added to the unMENU package config file were completely ignored.

2. You used a "windows" editor,  an editor that put carriage-return/newline pairs at the ends of lines.  The unMENU package files require lines ending in a newline only.  (as do most files in a Linux server)

 

What you needed to do was to add two additional PACKAGE_INSTALLATION lines in the apcupsd-unmenu-package.conf file.  Those two lines would look like this:

PACKAGE_INSTALLATION sed -i -e "s/^BATTERYLEVEL 5/BATTERYLEVEL 20/" /etc/apcupsd/apcupsd.conf

PACKAGE_INSTALLATION sed -i -e "s/^MINUTES 3/MINUTES 6/" /etc/apcupsd/apcupsd.conf

 

Those lines needed to be above the line that actually starts apcupsd, so the edits will be in place when it reads them.

 

You can use the Config View/Edit plug-in in unMENU to edit your package config file.  Or... you can download and use the attached file were I've already added the lines you need.

 

In the attached file, I've also added a third line that edits a line for an absolute timer.  It is distributed set to 0, disabling it, but you could set it to an explicit number of seconds. Set this to a non-zero value if you always wanted the shutdown to start after a specific number of seconds, regardless of the battery-level or the estimated number of remaining minutes.

 

The line below effectively does nothing (changes TIMEOUT 0 to TIMEOUT 0), but you could edit it if needed.

PACKAGE_INSTALLATION sed -i -e "s/^TIMEOUT 0/TIMEOUT 0/" /etc/apcupsd/apcupsd.conf

change to this if shutdown always will occur at 45 seconds of outage:

PACKAGE_INSTALLATION sed -i -e "s/^TIMEOUT 0/TIMEOUT 45/" /etc/apcupsd/apcupsd.conf

 

The three values, BATTERYLEVEL, MINUTES, and TIMEOUT are all used.  The first one reached will initiate the shutdown process.  If you set TIMEOUT to 600 seconds, but the MINUTES remaining drop below the configured value, the shutdown will occur even if you have not yet reached 10 minutes of outage.   (The default TIMEOUT 0 disables it, and it is not normally considered in the shutdown process with a smart UPS)

 

Once you put this new .conf file into place in your /boot/packages directory you will need to delete the existing apcupsd-3.14.3-i486-1kjz.tgz.auto_install and apcupsd-3.14.3-i486-1kjz.tgz.manual_install files, and then press the buttons on the package manager plug-in to re-create those two files.

 

Joe L.