# HOWTO: apcupsd with USB

## whiskeypriest

HOWTO: apcupsd with USB

BACKGROUND:

It all started last summer when the annual, unexplained micro-outages began rolling through my neighborhood again: my entire residence would lose power for roughly .5 seconds at exactly the same time each morning.  These outages were nothing the coffee maker and VCR couldnt handle, but they proved just enough to bounce every single one of my machines.  Annoying.

I purchased a couple APC UPS units (a Back-UPS CS350 for my routers, and a Back-UPS XS1000 for my two antediluvian servers) to solve the problem.  Both ran in dumb mode for months, i.e. there was no communication between the UPS and the machines they supported, no automated system shutdown in the event of complete battery exhaustion.  UPS plugs into wall, stuff plugs into UPS, done.  This setup allowed me to weather the outages of late summer in style and I wasnt too concerned about the lack of features

Needless to say, the winter months have been less forgiving to the local power supply.  After two outages that left both batteries completely drained (one of which found me dancing around some minor flooding, frantically performing manual shutdowns on my machines) I decided I needed something a bit more robust.  After some research, apcupsd seemed the obvious choice, so I set about implementing it on my newly-minted Gentoo systems.  The following was born from my experiences doing so, and the dearth of any comprehensive Gentoo-specific documentation on the subject.  I infer from the latter that there are either quite a few UPS units running in dumb mode on Gentoo installations, or Im just the ass that couldnt get this to work out of the box.  In either case, I figure this cant hurt.

A few things you ought to know before we get started

OBJECTIVES:

By the time youve gone through all this, you should have:USB support for your APC UPS.

Power management support allowing apcupsd to completely poweroff the system (rather than simply halting it, requiring a manual poweroff at the mains).

Functionality allowing apcupsd to control and monitor multiple systems over Ethernet in a master/slave configuration. 

The ability to monitor the status of your UPS with apcupsd via your favorite browser.PREREQUISITES:

This HOWTO assumes the following:You own an APC UPS attached via the supplied USB cable to a Gentoo installation.  I dont know anything about other cables, non-APC products, other Linux distributions, the UPS with the bad smell your brother found in the parking lot, etc.  La-la-la, I cant hear you

You will be performing these operations on an x86-based systemhowever, I have at least one report of this HOWTO functioning for AMD64 systems.

Your master and slave machines will both be running some version of Gentoo.  If youre mixing your operating systems, Id be interested to hear what was necessary to adapt these procedures.

You are familiar with the procedures and potential consequences of recompiling your own kernel.

You already have Apache configured and running on the system that will act as the master for apcupsd (namely the one the USB cables plugged into).  If youre not interested in the browser status aspect of this HOWTO, feel free to ignore this.

You understand enough about networking protocols (and your own network) to be dangerous.

You can use a text editor.If any of the above is not true, youre either in the wrong place or have bigger problems to worry about than playing with your UPS.

DISCLAIMERS, CAVEATS, ETCETERA:I am in no way, shape, or form associated with APC, the apcupsd project, or much of anything else.

I am frequently wrong.

The following procedures worked for me on my hardware this week.  YMMV.

You will reboot your machine(s).  Kiss that uptime goodbye for the time being.

This HOWTO is not a substitute for reading and understanding the extensive documentation in the apcupsd Users Manual.  I just bumped my head on a few things trying to implement the procedures outlined therein.

apcupsd runs as root.  These procedures are for home networks that have been properly secured against external factors where you trust every machine on your network and every person in your place of residence.  Having someone else arbitrarily poweroff your systems sort of defeats the purpose of owning a UPS, wouldnt you say?Right.  Had enough of this?  Then lets roll

KERNEL CONFIGURATION:

The first thing well need to do is recompile our kernel to support both USB and ACPI or APM on the system that will act as the master installation.  If you dont know whether your machine supports APM or ACPI, reboot and go root around in your BIOS options (usually under Power Management oddly enough).  If you see something like Enable ACPI [y/n]? you know what youve got and what the response to that [y/n] should be.  The rule seems to be that pre-millennium boards use APM, more recent hardware uses ACPI.  Just make a note of which youre using for now; well come back to it momentarily.  

One more thing: if youre using ACPI, you may want to add it to your USE settings in /etc/make.conf.  I didnt and lived to tell the tale, but its up to you.

A NOTE ON POWER MANAGEMENT: Since this guides inception, Ive received several reports indicating that neither APM nor ACPI is necessary for some systems to successfully perform an unassisted shutdown.  If your system already handles its power management needs to your satisfaction, Id advise not changing anything; if you run into problems you can always come back here and follow the steps below.  If it isnt broken

Now, drop into a console, su to root, and grab your favorite kernel sources:

```
# cd /usr/src/linux; make menuconfig
```

First, lets get the power management squared away.  Make sure the following are enabled in your kernel...for 2.4 kernels, yours might want to look like this:

```
General setup  --->

    [*] Power Management support

    < >   Advanced Power Management BIOS support

    ACPI Support  --->

       [*] ACPI Support

       < >   AC Adapter

       < >   Battery

       <M>   Button

       < >   Fan

       <M>   Processor

       < >   Thermal Zone

       < >   ASUS Laptop Extras

       < >   Toshiba Laptop Extras

       [ ]   Debug Statements

       [ ]   Relaxed AML Checking
```

For 2.6 kernels, try this:

```
Power management options (ACPI, APM)  --->

     [*] Power Management support

     [ ]   Software Suspend (EXPERIMENTAL) 

     [ ]   Suspend-to-Disk Support

          ACPI (Advanced Configuration and Power Interface) Support  --->

          [*] ACPI Support

          [ ]   Sleep States (EXPERIMENTAL)

          <*>   AC Adapter

          <*>   Battery

          <*>   Button

          < >   Fan

          <*>   Processor

          < >   Thermal Zone

          < >   ASUS/Medion Laptop Extras

          < >   Toshiba Laptop Extras

          [ ]   Debug Statements

          [ ]   Power Management Timer Support
```

Obviously, my master machine uses ACPI.  I found these options to be the minimum I was comfortable with; you may want more, and youre welcome to try less.  

If youre using APM, youll probably want to disable ACPI support and try something like this for your 2.4 kernel:

```
General setup  --->

    [*] Power Management support

    <*>   Advanced Power Management BIOS support

    [ ]     Ignore USER SUSPEND

    [*]     Enable PM at boot time

    [ ]     Make CPU Idle calls when idle

    [ ]     Enable console blanking using APM

    [ ]     RTC stores time in GMT

    [*]     Allow interrupts during APM BIOS calls

    [*]     Use real mode APM BIOS call to power off

    ACPI Support  --->
```

...or this, for your 2.6 kernel:

```
Power management options (ACPI, APM)  --->

     [*] Power Management support

     [ ]   Software Suspend (EXPERIMENTAL)

     [ ]   Suspend-to-Disk Support

        APM (Advanced Power Management) BIOS Support  --->

        <M> APM (Advanced Power Management) BIOS support

        [*]   Ignore USER SUSPEND (NEW)

        [ ]   Enable PM at boot time (NEW)

        [ ]   Make CPU Idle calls when idle (NEW)

        [ ]   Enable console blanking using APM (NEW)

        [ ]   RTC stores time in GMT (NEW)

        [*]   Allow interrupts during APM BIOS calls (NEW)

        [*]   Use real mode APM BIOS call to power off (NEW)
```

With these options enabled in the kernel, your machine should power itself off on a halt without you having to stab the power button.

As a side note, Ive read that ACPI and SMP do not play well together.  There are several threads about this on the forums, so I wont go into itjust be advised that if youre running multiple processors or one of those new-fangled Pentiums with HT technology, this may be an issue for you.

Next, well get USB support set for our UPS (2.4 kernels first):

```
USB support  --->

    <M> Support for USB

    [ ]   USB verbose debug messages

    --- Miscellaneous USB options

    [*]   Preliminary USB device filesystem

    [ ]   Enforce USB bandwidth allocation (EXPERIMENTAL)

    --- USB Host Controller Drivers

    < >   EHCI HCD (USB 2.0) support (EXPERIMENTAL)

    < >   UHCI (Intel PIIX4, VIA, ...) support

    < >   UHCI Alternate Driver (JE) support

    <M>   OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support

    < >   SL811HS Alternate (x86, StrongARM, isosynchronous mode)

    < >   SL811HS (x86, StrongARM) support, old driver

    --- USB Device Class drivers

    < >   USB Audio support

    < >   USB Bluetooth support (EXPERIMENTAL)

    < >   USB MIDI support

    ---   SCSI support is needed for USB Storage

    < >   USB Modem (CDC ACM) support

    < >   USB Printer support

    --- USB Human Interface Devices (HID)

    <M>   USB Human Interface Device (full HID) support

    ---     Input core support is needed for USB HID input layer or HIDBP

    [*]     /dev/hiddev raw HID device support

    < >   USB HIDBP Keyboard (basic) support

    < >   USB HIDBP Mouse (basic) support

    < >   Aiptek 6000U/8000U tablet support

    < >   Wacom Intuos/Graphire tablet support

    < >   KB Gear JamStudio tablet support

    < >   Griffin Technology PowerMate support
```

Now, for 2.6 kernels:

```
Device Drivers  --->

     USB support  --->

          <*> Support for Host-side USB

          [ ]   USB verbose debug messages

          ---   Miscellaneous USB options

          [*]   USB device filesystem

          [ ]   Enforce USB bandwidth allocation (EXPERIMENTAL)

          [ ]   Dynamic USB minor allocation (EXPERIMENTAL)

          ---   USB Host Controller Drivers

          < >   EHCI HCD (USB 2.0) support

          <*>   OHCI HCD support

          < >   UHCI HCD (most Intel and VIA) support

          ---   USB Device Class drivers

          < >   USB Audio support

          < >   USB Bluetooth TTY support

          < >   USB MIDI support

          < >   USB Modem (CDC ACM) support

          < >   USB Printer support

          < >   USB Mass Storage support

          ---   USB Human Interface Devices (HID)

          <*>   USB Human Interface Device (full HID) support

          [*] HID input layer support

          [ ]   Force feedback support (EXPERIMENTAL)

          [*] /dev/hiddev raw HID device support

          < > Aiptek 6000U/8000U tablet support

          < > Wacom Intuos/Graphire tablet support

          < > KB Gear JamStudio tablet support

          < > Griffin PowerMate and Contour Jog support

          < > MicroTouch USB Touchscreen Driver

          < > eGalax TouchKit USB Touchscreen Driver

          < > X-Box gamepad support

          < > ATI / X10 USB RF remote control

          --- USB Imaging devices

          < > USB Mustek MDC800 Digital Camera support (EXPERIMENTAL)

          < > Microtek X6USB scanner support

          < > HP53xx USB scanner support (EXPERIMENTAL)

          --- USB Multimedia devices

          < > DABUSB driver

          --- Video4Linux support is needed for USB Multimedia device support

          --- USB Network adaptors

          < > USB CATC NetMate-based Ethernet device support (EXPERIMENTAL)

          < > USB KLSI KL5USB101-based ethernet device support

          < > USB Pegasus/Pegasus-II based ethernet device support

          < > USB RTL8150 based ethernet device support (EXPERIMENTAL)

          < > Multi-purpose USB Networking Framework

          --- USB port drivers

          USB Serial Converter support  --->

          --- USB Miscellaneous drivers

          < > EMI 6|2m USB Audio interface support

          < > EMI 2|6 USB Audio interface support

          < > Texas Instruments Graph Link USB (aka SilverLink) cable support

          < > USB Auerswald ISDN support (EXPERIMENTAL)

          < > USB Diamond Rio500 support (EXPERIMENTAL)

          < > USB Lego Infrared Tower support (EXPERIMENTAL)

          < > USB LCD driver support

          < > USB LED driver support

          < > Cypress USB thermometer driver support

          < > USB PhidgetServo support

          < > USB testing driver (DEVELOPMENT)

          USB Gadget Support  --->
```

There are a couple things to note here.  First, make sure you build support for USB as a module in 2.4 kernels only; builtin is preferable for 2.6 kernels.  

Second, the Preliminary USB device filesystem is very important (as I found when I took my first swing at this project).  I had neglected to build this in; the result gave me a seemingly functional installation with full communication between apcupsd and the UPS.  I just couldnt get apcupsd to shutdown the machine, which I viewed as a rather important piece of functionality.  Make sure its there.

Next, be sure to build the appropriate driver for your chipset.  Mine is made by SiS, hence I use the OHCI driverif you use Intel or VIA, you need the UHCI driver.  If you dont know what you use, do an Alt-F2 (or open a new console window, or whatever) and run:

```
# /sbin/lspci v
```

This will list all the devices on the PCI bus; you should find your answer somewhere in there.

Note that I dont have anything else enabled in the way of printers, audio, Bluetooththats because the UPS is the only USB device plugged into this system.  Your needs may be different.

Thats it for the kernel.  Hit Esc twice, and do the usual for 2.4 kernels:

```
# make dep && make bzImage modules modules_install

# mount /boot/

# cp arch/i386/boot/bzImage /boot/kernel-<your-kernel-version-goes-here>

# cp System.map /boot/System.map-<your-kernel-version-goes-here>

# cp .config /boot/config-<your-kernel-version-goes-here>
```

...or, if you have a 2.6 kernel:

```
# make && make modules_install

# mount /boot/

# cp arch/i386/boot/bzImage /boot/kernel-<your-kernel-version-goes-here>

# cp System.map /boot/System.map-<your-kernel-version-goes-here>

# cp .config /boot/config-<your-kernel-version-goes-here>
```

Remember to update bootloader configuration if necessary.

Finally, this would be a good time to

```
# emerge sync; emerge hotplug; rc-update add hotplug default
```

if its not already running on your installation.

Remember that whole master/slave thing about controlling two machines with one UPS?  If youve got a standalone machine (one UPS controlling one machine) youre doneif, however, youve got multiple machines on the same UPS youll want to head over to your slave machine at this point and make sure that it also has the appropriate power management built into its kernel.  Whether you compile with USB support on the slave is up to youits not necessary for our purposes here, though.

If everything looks good, make sure your UPS is plugged in at both ends and reboot into your new kernel.

CHECKING YOUR USB SUBSYSTEM:

For a more detailed explanation, see the document from which this was shamelessly cribbed.

Basically, you just run:

```
# cat /proc/bus/usb/devices
```

You should see something analogous to the following:

```
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=1.5 MxCh= 0

D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1

P:  Vendor=051d ProdID=0002 Rev= 1.00

S:  Manufacturer=American Power Conversion

S:  Product=Back-UPS 350 FW: 5.2.I USB FW: c1 

S:  SerialNumber=BB0115017954

C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 30mA

I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=hid

E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl= 10ms
```

To quote the apcupsd Users Manual, In general, if you see your UPS model in the S field, you're done.  If you dont, you have a problem.  Double-check your kernel configuration, try unplugging and re-plugging the USB cable, make sure the cable is firmly seated at both ends, and see the link above for more troubleshooting tips.  If none of this helps, youre unfortunately now outside the scope of this HOWTO.  Seek help from your local guru.

Assuming that went according to plan, now would also be a good time to make sure our power management is working properly.

```
# shutdown h now
```

Your system should power itself down without any manual assistance from youif it doesnt, youve got some more homework to do.  Dont forget to check your slave machine for this functionality as well.

Good so far?  Then lets get apcupsd installed on our master machine.

INSTALLING AND CONFIGURING APCUPSD:

As usual, this is an absolutely painless process in Gentoo.  Emerge apcupsd and set it to start automatically.

```
# emerge sync; emerge apcupsd; rc-update add apcupsd default
```

VERY IMPORTANT NOTE: As of apcupsd-3.10.10, the apccontrol file located in /etc/apcupsd might need to be edited.  The problem seems to have been corrected in apcupsd-3.10.10-r1, but you may as well check this now before proceeding:

```
# nano -w /etc/apcupsd/apccontrol
```

Down around line 89 is what you're looking for.  You might see a redundant ;; in the mainsback section of the apccontrol file, like so:

```
mainsback)

   echo "Power has returned on UPS ${2}..." | wall

   if [ -f /etc/apcupsd/powerfail ] ; then

      printf "Continuing with shutdown."  | wall

   fi

   ;;

;;
```

If this is the case, remove the first instance of the ;; so your edited section looks like this:

```
mainsback)

   echo "Power has returned on UPS ${2}..." | wall

   if [ -f /etc/apcupsd/powerfail ] ; then

      printf "Continuing with shutdown."  | wall

   fi

;;
```

If you've upgraded from an earlier version of apcupsd you'll need to fix this, then restart apcupsd.  If you're using apcupsd-3.10.10 as your first installation, save your changes and move on.  

FAILURE TO DO THE ABOVE MAY RESULT IN REDUCED FUNCTIONALITY, SYSTEM HANGS, SPONTANEOUS DECAPITATION, ETC.

Now its time to start configuring our master installation:

```
# nano -w /etc/apcupsd/apcupsd.conf
```

As you can see, theres quite a bit in here.  Feel free to consult the apcupsd Users Manual for some sample configurations and advice; Ill provide mine below and try to hit the important stuff, but its extremely beneficial to understand whats happening within this file.

```
## apcupsd.conf v1.1 ##

#

#  for apcupsd release 3.10.9 (31 December 2003)  gentoo

#  sample master configuration file

UPSNAME                              <some-unique-string>

UPSCABLE                             usb

UPSTYPE                              usb

LOCKFILE                             /var/lock

ONBATTERYDELAY                       6

BATTERYLEVEL                         5

MINUTES                              3

TIMEOUT                              0

ANNOY                                300

ANNOYDELAY                           60

NOLOGON                              disable

KILLDELAY                            0

NETSERVER                            on

NISPORT                              3551

EVENTSFILE                           /var/log/apcupsd.events

EVENTSFILEMAX                        10

UPSCLASS                             netmaster

UPSMODE                              net

NETTIME                              10

NETPORT                              6666

SLAVE                                <your-slave-machines-IP-address>

USERMAGIC                            <some-unique-string>

STATTIME                             0

STATFILE                             /var/log/apcupsd.status

LOGSTATS                             off

DATATIME                             0
```

There are several things to note here.For our purposes, both UPSCABLE and UPSTYPE must be set to usb in order to establish communication with the UPS.

Youll notice that the DEVICE parameter does not appear here.  Thats because its been commented out of my apcupsd.conf file.  See this for the reason why.

Youll also notice that NISIP does not appear here, as it has also been commented out.  See this thread (again) for the reason why.

The NETSERVER and NISPORT settings are crucial to obtaining status information from apcupsd.  Make sure they appear as listed in the above file.

UPSCLASS must be set to netmaster and UPSMODE must be set to net in order for this installation to act as the master.  If youll be running the standalone configuration without a slave, see below.

SLAVE is the IP address or FQDN of your slave machine.

USERMAGIC is a basic form of authentication between the master and slave.  Break out your favorite password generator and enter the results here.  Make sure youve got it handy somewhere; youll need it again for the slave machines configuration file.For those of you planning on running with one UPS powering one machine, youll want something like the following:

```
## apcupsd.conf v1.1 ##

#

#  for apcupsd release 3.10.9 (31 December 2003)  gentoo

#  sample standalone configuration file

UPSNAME                              <some-unique-string>

UPSCABLE                             usb

UPSTYPE                              usb

LOCKFILE                             /var/lock

ONBATTERYDELAY                       6

BATTERYLEVEL                         5

MINUTES                              3

TIMEOUT                              0

ANNOY                                300

ANNOYDELAY                           60

NOLOGON                              disable

KILLDELAY                            0

NETSERVER                            on

NISPORT                              3551

EVENTSFILE                           /var/log/apcupsd.events

EVENTSFILEMAX                        10

UPSCLASS                             standalone

UPSMODE                              disable

STATTIME                             0

STATFILE                             /var/log/apcupsd.status

LOGSTATS                             off

DATATIME                             0
```

Note the differences between the files:NETTIME, NETPORT, SLAVE, and USERMAGIC are no longer relevant and have been removed.

UPSCLASS must be set to standalone and UPSMODE must be set to disable.Once youre satisfied with your apcupsd.conf file, save it and proceed to...

STARTING APCUPSD:

Its time to kick this thing in the guts and see if it runs.  Start apcupsd manually with:

```
# /etc/init.d/apcupsd start
```

If youve followed the configuration guidelines above, you should get a clean start from apcupsd.  

```
  * Starting APC UPS daemon...                                   [ ok ]
```

If you don't get a clean start, you need to double-check your previous work.  Check your log with

```
# tail /var/log/messages
```

to see what went wrong.  

NOTE: Ive experienced problems with the apcupsd process going undead on me when it gets a bad start; attempts to stop it, kill it, or restart it are futile.  If you get a bad start, youll need to do:

```
# /etc/init.d/apcupsd zap
```

This will allow you a clean start (after youve changed something, presumably) rather than forcing a reboot of the system to clear the process.

ANOTHER NOTE ON BAD STARTS: You may get an error message similar to the following:

```
apcupsd FATAL ERROR in linux-usb.c at line 684 

Cannot open UPS device:
```

Before ransacking your kernel configuration or the apcupsd.conf file, try the following procedure.  Make sure apcupsd is stopped and do a running tail of your log:

```
# /etc/init.d/apcupsd zap

# tail -f /var/log/messages
```

Now unplug your USB cable from your machine and plug it back in.  You should see the stats for your UPS pop up in the tail you've got running.  Cancel the tail and attempt to start apcupsd again; it should start with no problems if everything else is in order.  If you don't see your UPS in the tail after a few unplug/replug attempts, you probably do need to go back and check your kernel configuration and apcupsd.conf file.

Now it's time to test apcupsd for full functionality.  We'll run through each of these tests in brief; for more detailed testing information, please refer to the invaluable-and-frequently-cited apcupsd User's Manual section on this subject.

ANOTHER NOTE: These tests are applicable for installations running apcupsd in both master and standalone modes.  Standalone users should not see messages about apcupsd being unable to connect to its slave, but I doubt this will bother them much.

A FURTHER NOTE: During these tests, you may not get wall messages to your console; instead, you may see things like the following in /var/log/messages:

```
Feb 10 15:36:17 <your-host-here> sSMTP[2626]: Unable to locate mail

Feb 10 15:36:17 <your-host-here> sSMTP[2626]: Cannot open mail:25

Feb 10 15:36:17 <your-host-here> wall[2630]: wall: user root broadcasted 1 lines (42 chars)
```

These have to do with system configurations that I'm not particularly interested in.  See the man pages or your local guru if this bothers you.

ectospasm notes that you can drop the wall messages entirely (if they annoy you) by commenting out the WALL=wall variable in /etc/apcupsd/apccontrol, like so:

```
#

# These variables are needed for set up the autoconf other variables.

# 

prefix=/usr

exec_prefix=${prefix}

APCPID=/var/run/apcupsd.pid

APCUPSD=/usr/sbin/apcupsd

SHUTDOWN=/sbin/shutdown

SCRIPTSHELL=/bin/sh

SCRIPTDIR=/etc/apcupsd

# WALL=wall
```

Note that you'll have to do this each time you upgrade apcupsd.

TESTING APCUPSD  Process-Status Test:

Once you've got apupsd started, execute the following command:

```
# ps fax
```

You should see something similar to the following in the output:

```
  2429 ?        S      0:00  \_ /usr/sbin/apcupsd

  2430 ?        S      0:00      \_ /usr/sbin/apcupsd

  2431 ?        S      0:00      \_ /usr/sbin/apcupsd
```

If you only see one instance of apcupsd running, don't sweat it unless the communication test fails.  If there are no instances of apcupsd, go back and check /var/log/messages...

TESTING APCUPSD  Logging Test:

Now that we know the apcupsd processes are running, do a tail of your system log file:

```
# tail /var/log/messages
```

You should see something similar to the following:

```
Feb 11 11:07:37 <your-host-here> apcupsd[2411]: apcupsd 3.10.9 (31 December 2003) gentoo startup succeeded

Feb 11 11:07:37 <your-host-here> apcupsd[2431]: NIS server startup succeeded

Feb 11 11:08:07 <your-host-here> apcupsd[2430]: Slave connection failed Connection refused! Down slave 0
```

Don't worry about the failed slave connection; we haven't set our slave up yet.  If you don't see the message about the NIS server successfully starting, check your apcupsd.conf file and make sure you enabled the proper options (as outlined above).

TESTING APCUPSD  apcaccess Test:

Run the following:

```
# apcaccess status
```

Your output should resemble the following:

```
APC      : 001,027,0653

DATE     : Wed Feb 11 11:12:37 EST 2004

HOSTNAME : <your-host-here>

RELEASE  : 3.10.9

VERSION  : 3.10.9 (31 December 2003) gentoo

UPSNAME  : APC

CABLE    : USB Cable

MODEL    : Back-UPS 350

UPSMODE  : Net Master

STARTTIME: Wed Feb 11 11:07:37 EST 2004

SHARE    : NetworkUPS

STATUS   : ONLINE

BCHARGE  : 100.0 Percent

TIMELEFT :  43.0 Minutes

MBATTCHG : 5 Percent

MINTIMEL : 3 Minutes

MAXTIME  : 30 Seconds

NUMXFERS : 0

TONBATT  : 0 seconds

CUMONBATT: 0 seconds

XOFFBATT : N/A

STATFLAG : 0x02000008 Status Flag

MANDATE  : 2003-05-15

BATTDATE : 2003-05-15

NOMBATTV :  12.0

FIRMWARE : 5.4.D USB FW: c1

APCMODEL : Back-UPS 350

END APC  : Wed Feb 11 11:13:36 EST 2004
```

There may be more; there may be less.  It will depend on your UPS.  Again, you must have NETSERVER and NISPORT defined in your apcupsd.conf file in order for this test to succeed.  Check this first if there's a problem.

If you see something resembling:

```
attach_shmarea: shared memory version mismatch (or UPS not yet ready to report)
```

or if all the status values come back zero, give apcupsd another minute to initiate communication with the UPS, then try running the apcaccess command again.

TESTING APCUPSD  Communications Test:

If everything's gone smoothly, we now need to ascertain whether the UPS and apcupsd are communicating properly.  Do a running tail of the apcupsd events file:

```
# tail -f /var/log/apcupsd.events
```

Now disconnect the USB cable from the UPS or from your machine.  You should see the following appear in the apcupsd.events file:

```
Wed Feb 11 11:15:59 EST 2004  Communications with UPS lost.

Wed Feb 11 11:16:07 EST 2004  Slave connection failed Connection refused! Down slave 0
```

Again, ignore the messages about the slave.

ectospasm notes that is may take some time for this message to appear.  Remember, patience is a virtue.

Reconnect the USB cable.  You should see:

```
Wed Feb 11 11:16:20 EST 2004  Communications with UPS restored.

Wed Feb 11 11:16:37 EST 2004  Slave connection failed Connection refused! Down slave 0
```

All set?  Cancel the tail and move to the next test.  

If you don't see these messages, you need to correct the problem before proceeding.  Did you emerge hotplug?  Kernel compiled correctly?

TESTING APCUPSD  Simulated Power Fail Test:

First we'll need to reconfigure a few things to make sure apcupsd doesn't actually shutdown our system.  Somewhat counterintuitive, I know, but we're still testing the installation.  Do the following:

```
# cp /etc/apcupsd/apccontrol /etc/apcupsd/apccontrol.save

# cp /etc/apcupsd/safe.apccontrol /etc/apcupsd/apccontrol
```

This substitutes the safe version of apccontrol for our operational version.

We're about to pull the plug.  Do I need to tell you to make sure your system is properly backed up?  Do another running tail of the apcupsd events file:

```
# tail -f /var/log/apcupsd.events
```

...and disconnect your UPS from its outlet.  You should see something like the following appear in your apcupsd.events file:

```
Wed Feb 11 11:19:52 EST 2004  Power failure.

Wed Feb 11 11:19:58 EST 2004  Running on UPS batteries.
```

Give this whole process about fifteen seconds for the messages to appear; after the second message, reconnect the power.  You should see:

```
Wed Feb 11 11:20:06 EST 2004  Power is back. UPS running on mains.

Wed Feb 11 11:20:08 EST 2004  Slave connection failed Connection refused! Down slave 0
```

If all's well here, cancel the tail and we'll do a simulated power down of the system.  Keep the safe version of apccontrol where it is, and backup your apcupsd.conf file:

```
# cp /etc/apcupsd/apcupsd.conf /etc/apcupsd/apcupsd.save
```

Now edit your apcupsd.conf file's TIMEOUT value to read 30 instead of zero.  This will cause apcupsd to attempt a shutdown of the system thirty seconds after it detects a power failure.  Save your new configuration file.  You'll need to restart apcupsd for the changes to take effect:

```
# /etc/init.d/apcupsd restart
```

Start another running tail of /var/log/apcupsd.events, and pull the plug.  Your output should resemble the following:

```
Wed Feb 11 11:35:27 EST 2004  Power failure.

Wed Feb 11 11:35:33 EST 2004  Running on UPS batteries.
```

If you've done everything right, the following will appear after roughly thirty seconds:

```
Wed Feb 11 11:36:04 EST 2004  Reached run time limit on batteries.

Wed Feb 11 11:36:04 EST 2004  Initiating system shutdown!

Wed Feb 11 11:36:04 EST 2004  User logins prohibited
```

When you see this message, reconnect the power.  The following should appear:

```
Wed Feb 11 11:36:07 EST 2004  Cancelling shutdown

Wed Feb 11 11:36:07 EST 2004  Power is back. UPS running on mains.

Wed Feb 11 11:36:07 EST 2004  Allowing logins
```

apcupsd should acknowledge that power has been restored and cancel the shutdown.

Replace your apccontrol and apcupsd.conf files, restart apcupsd and we'll move on to the final test...

```
# cp /etc/apcupsd/apccontrol.save /etc/apcupsd/apccontrol

# cp /etc/apcupsd/apcupsd.save /etc/apcupsd/apcupsd.conf

# /etc/init.d/apcupsd restart
```

TESTING APCUPSD  Full Power Down Test:

System still properly prepared for catastrophic failure?  Then let's do it for real.

You have two options here: simulate a complete loss of power by yanking the plug and waiting for the batteries to exhaust themselves, or set a low TIMEOUT value (e.g. 60) in apcupsd.conf.  Remember to restart apcupsd if you choose the latter option.  Either way, your system should power itself off once it has reached the appropriate parameter: roughly sixty seconds after unplugging if you chose to modify the TIMEOUT value as above, or when the battery reaches either 5% or has only three minutes of runtime remaining (whichever comes first, assuming you used the values from my sample apcupsd.conf files).  These values are set (where else?) in your apcupsd.conf file, and can be modified to taste.  You can run a tail of /var/log/apcupsd.events if you're into watching that sort of thing while your UPS bleats at you incessantly.

TESTING APCUPSD  The Aftermath

If everything went flawlessly, congratulations.  You now have a functional master (or standalone) installation of apcupsd.  If you altered the TIMEOUT value in apcupsd.conf, remember to set it back to 0 and restart apcupsd before you continue.

If something didn't go as planned, double-check your configuration file; check that you restored the original version of apccontrol after the Simulated Power Fail Test; make sure your UPS is still communicating successfully with apcupsd, and so on. 

Now that we've got that sorted, let's set up our slave.  If you're running apcupsd in standalone mode, you can skip this section and move on to OBTAINING UPS STATUS VIA YOUR BROWSER.  If you're not interested in that either, you're done.  Smoke 'em if you got 'em.

INSTALLING, CONFIGURING AND STARTING THE APCUPSD SLAVE:

Now it's time to get our slave up and running.  This is much less involved as we're already familiar with the basic principles, right?

```
# emerge sync; emerge apcupsd; rc-update add apcupsd default
```

Now edit your slave's apcupsd.conf file.  Mine looks like this:

```
## apcupsd.conf v1.1 ##

#

#  for apcupsd release 3.10.9 (31 December 2003)  gentoo

#  sample slave configuration file

UPSCABLE                             ether

UPSTYPE                              smartups

LOCKFILE                             /var/lock

NOLOGON                              disable

NETSERVER                            on

NISPORT                              3551

EVENTSFILE                           /var/log/apcupsd.events

EVENTSFILEMAX                        10

UPSCLASS                             netslave

UPSMODE                              net

NETPORT                              6666

MASTER                               <your-master-machines-IP-address>

USERMAGIC                            <some-unique-string>
```

While I retain the original form and content of the apcupsd.conf file on my master installation (i.e. I just change values and comment lines in/out) my slave file literally looks like what you see above.  Very simple, very easy; feel free to just copy it into your favorite text editor and change what you need.

A few (very important) notes on the above:UPSCABLE must be set to ether.

UPSTYPE must be set to smartups.  I'm not kidding.  This was worth twenty-four hours of aggravation when I was attempting to set my first slave.  I've read documentation suggesting that the master and slave must have the same UPSTYPE.  I've read documentation stating that UPSTYPE must be set to net just like UPSMODE.  Neither of these settings worked on my installation.  Just take my word for it: set UPSTYPE to smartups and don't look back.

Unless you want to be locked out of your slave machine the moment your UPS switches to battery, I'd set the NOLOGON value to disable.

Neither EVENTSFILE nor EVENTSFILEMAX are necessary, but I like to see what my slave's been up to even though the master calls all the shots.  It's your decision to include or omit this.

Remember when I told you to make a note about your master installation's USERMAGIC setting?  Enter the same thing here or you'll be sorry.Save your file, and start apcupsd manually.  You should get a clean start:

```
# /etc/init.d/apcupsd start

  * Starting APC UPS daemon...                                   [ ok ]
```

If you look in /var/log/apcupsd.events, you should see something like the following:

```
Wed Feb 11 15:39:08 EST 2004  apcupsd 3.10.9 (31 December 2003) gentoo startup succeeded

Wed Feb 11 15:39:38 EST 2004  Connect from master <your-master-machines-IP-address> succeeded
```

Likewise, you can run back to your master machine (it is still running apcupsd, right?) and check its apcupsd.events file for a similar message:

```
Wed Feb 11 15:39:38 EST 2004  Connect to slave <your-slave-machines-IP-address> succeeded
```

Note that it may take a minute or more for the master and slave to contact each other.  Be patient.  If errors occur, check your apcupsd.conf files.  Also, check to make sure your master is listed in your /etc/hosts file; apcupsd will wait for networking before starting, but better safe than sorry.  If everything is in order there, it's time to start troubleshooting your network connectivity.  Good luck.

TESTING THE APCUPSD SLAVE:

This goes just like it did for the master; just remember, your slave takes its orders from the master, so all file reconfiguration for testing should be done on the master, not on the slave.  If you're lazy, overconfident, or just don't care by this point you can do what I did: once you've established the master and slave are communicating, pull the plug and see if the slave powers down with the master.

Remember to reset any configuration files to their operational states after testing and to restart apcupsd if you made any changes.

That's it.  You now have a slave that will shutdown when its master tells it.  Note that you can add BATTERYLEVEL, MINUTES, and TIMEOUT settings to the above slave configuration file to have the slave shutdown before the master, thereby conserving more battery for the master's use.

OBTAINING UPS STATUS VIA YOUR BROWSER:

First, you'll need to edit the /etc/apcupsd/hosts.conf file on your master installation to tell apcupsd which machines to monitor.  Mine looks like this:

```
MONITOR <your-master-machines-IP-address> <your-master-machines-name>

MONITOR <your-slave-machines-IP-address> <your-slave-machines-name>
```

I'd restart apcupsd and Apache just to be safe.

Now then...you had Apache installed, configured, and operational before you emerged apcupsd on your master machine, right?  If this is the case, direct your browser to:

```
http://<your-master-machines-IP-address>/apcupsd/multimon.cgi
```

You should see something like this.  If you click on the name of the master or the slave in this display, you should see something like this.

Your stats may or may not be as extensive as those noted in the above links; it will depend on your UPS.  

You're done.  When emerged, apcupsd automatically creates these files and directories in your /var/www directory (assuming a default Apache configuration).  It's that simple...and if it's not, you need better help than I can give you here.

FINISHING UP:

Did you replace all your test configuration files with the proper ones?  Are all your TIMEOUT values set to 0?  Did you plug the UPS back in?

Stellar.  I'd reboot both machines for good measure; bring the master online first, then the slave.  Make sure apcupsd starts automatically (and properly) on both machines, check your logs, and relax.  You're now running your UPS in smart mode...

CALIBRATION:

Oh, and one last thing.  This is as good a place as any to talk about calibration of the UPS unit.  It has recently become apparent that some (if not all) of the UPS units need to be calibrated in order to achieve their proper runtime while operating under load during a power failure.  This has been confirmed as a necessity for the Back-UPS RS 1500; it can't hurt to follow this procedure for other APC UPS units as well.

First, if you're reading this prior to purchasing or installing a new APC UPS, I strongly recommend following the manufacturer's advice on charging the battery for the first time.  For those without their manuals handy, that's usually a minimum of eight hours without anything else being plugged into the unit.

Once your unit has been properly charged, place the unit under at least a 50% load (you can monitor this either with your browser or apcaccess).  Now disable apcupsd and yank the plug, letting the battery run until it is completely dead.  

NOTE: It probably goes without saying, but you may not want to use your expensive server or gaming rig to run the battery into the ground (especially since we're disabling apcupsd).  I'd think about loading the UPS unit with another (less valuable) appliance and simply using your system to ascertain the actual load.  I'm not going to make any recommendations about what to load the UPS with, but please, use common sense.

Plug the UPS unit back into the wall and allow it to recharge completely.  This should greatly improve the accuracy of the TIMELEFT estimate (and consequently, your actual runtime with apcupsd).

Thanks go to ectospasm for finding this issue and chasing it down, as well as Adam Kropelin for the providing the answer.

NOTES ON MISCELLANEOUS FUNCTIONALITY:Currently, apcupsd on USB UPS units does not send the UPS into hibernation when it powers down the system(s) it supports.  This means that while apcupsd will monitor the status of the UPS and shutdown its supported system(s) as appropriate, it will not automatically bring the UPS and its supported systems(s) back online when power returns, as the UPS itself is never shut down (unless, of course, youre without power long enough that the UPS actually exhausts itself).  Please see this section of the Troubleshooting apcupsd with USB thread for more details, but this functionality should be enabled sometime in the near future.  Once apcupsd includes this feature for USB UPS units, Ill update this document with general guidelines regarding the procedure for making sure your system(s) come back to life automatically following a UPS-induced shutdown.

UPDATE: mark_lagace has developed a temporary workaround for this lack of functionality.  Please see this section of this thread for his solution.  If you're going to implement it, please read it carefully and take all the necessary precautions.  Thanks, Mark!

As noted in the OBTAINING UPS STATUS VIA YOUR BROWSER section, the amount of information your UPS reports will vary depending on your modelfor example, my Back-UPS RS 1000 reports line voltage, while my two Back-UPS XS 800s do not.  I may eventually include a separate section detailing the vagaries of the individual APC models, but for the time being this HOWTO will only encompass what I consider to be the primary functions of apcupsd, i.e. basic monitoring of the UPS unit itself and controlled shutdown of its supported system(s) according to user-defined parameters.CLOSING COMMENTS:

I can't say enough about the apcupsd project.  If you're having problems, look there first.  Much of this HOWTO was derived (or blatantly copied) from their work.  Send them money, flowers, hardware, etc.

This document was lovingly crafted on OpenOffice and represents the whole of my knowledge on apcupsd.  Any errors or omissions are mine alone.  I would welcome any comments, corrections or further information on this daemon; I've only scratched the surface of what it can do and would like to hear about others' experience with/uses for it.

Finally, in September 2004 this HOWTO and its ensuing thread finally broke the three-page mark, necessitating (at least in my mind) the need for a separate topic to discuss problems with installation and execution.  Therefore, if you're having problems please read through the remainder of this thread first; if you don't find an answer there, please post to the Troubleshooting apcupsd with USB thread.

CHANGELOG:

02.14.04: Edited the KERNEL CONFIGURATION section to reflect new minimal configuration options.

02.16.04: Edited the sample slave configuration file in INSTALLING, CONFIGURING AND STARTING THE APCUPSD SLAVE to include the NOLOGON value and a note beneath regarding the importance of same.

02.21.04: Edited the STARTING APCUPSD section to advise of a possible need to unplug/replug the USB cable.

03.05.04: Edited the INSTALLING AND CONFIGURING APCUPSD section regarding the necessary change in the /etc/apcupsd/apccontrol file for apcupsd-3.10.10.  Also qualified the 2.6 kernel disclaimer.

04.22.04: The /etc/apcupsd/apccontrol file for apcupsd-3.10.10-r1 seems to have corrected the above issue, noted same in the INSTALLING AND CONFIGURING APCUPSD section.

09.10.04: Edited the KERNEL CONFIGURATION section to include suggested parameters for both 2.4 and 2.6 kernels; started the Troubleshooting apcupsd with USB thread.

10.07.04: Edited the KERNEL CONFIGURATION section to include advice regarding power management; edited the PREREQUISITES section to include the first-reported successful execution of these procedures on AMD64 hardware; added the NOTES ON MISCELLANEOUS FUNCTIONALITY section.

10.30.04: Added the CALIBRATION section after recent events on the Troubleshooting apcupsd with USB thread.

12.31.04: Added a link to mark_lagace's workaround for the UPS killpower issue discussed in the NOTES ON MISCELLANEOUS FUNCTIONALITY section.  Added links here as well, I suppose.

01.31.05: Edited the TESTING APCUPSD  Communications Test and STARTING APCUPSD sections per suggestions from ectospasm.Last edited by whiskeypriest on Mon Jan 31, 2005 11:14 pm; edited 11 times in total

----------

## ckdake

So cool! Wow.  Great howto.  As soon as I can afford getting a UPS for my desktop I'm going to have to try it out.  Right now my desktop just cuts off, the laptop gets confused because the external harddrives die, and I have to run down and shut down the server because its on a 6 year old UPS with mayybe 2 minutes of battery life when the power goes out...  This howto is definitely in my bookmarks. Thanks.

----------

## whiskeypriest

CHANGELOG:

I recently emerged the latest version of hotplug and noticed the following at startup:

```
* Starting USB and PCI hotplugging...

** can't synthesize input events - /proc/bus/input/devices missing
```

Thinking that this might have something to do with my input core support, I tried enabling and disabling various options therein, then disabling the input core support entirely (taking HID input layer support with it).  I can now definitively say that:input core support and HID input layer support are not necessary to the HOWTO.

/dev/hiddev raw HID device support is very necessary to the HOWTO.NOTE: Please remember that your needs may be different from mine...all I'm saying is that I can get away without the above options enabled in my kernel and still maintain the functionality outlined in the above HOWTO.

DOCUMENT EDITED TO REFLECT NEW MINIMAL KERNEL CONFIGURATION.

...none of which solved the initial issue with hotplug, mind you.

For that, see this bug.  I edited /etc/hotplug/input.rc as suggested here and rebooted without incident.

----------

## Reducer2001

I followed the instructions to a T, here's the error I get:

```
apcupsd FATAL ERROR in linux-usb.c at line 684

Cannot open UPS device:

```

I assume I compiled something wrong, any clues what?  Running Gentoo 2.4 sources.

Jason

----------

## whiskeypriest

I assume you're referring to a netmaster or standalone configuration, rather than problems you're having with a netslave...

From the error, it looks like your UPS is having a problem communicating over USB with apcupsd.  First things I'd check:Did you compile USB support as a module?

Do you have the correct USB driver for your chipset (UHCI, OHCI, et al.)?

Did you build Preliminary USB device filesystem, USB HID support, and /dev/hiddev raw HID device support into your kernel?

Did you successfully compile and reboot into your new kernel?

Can you see your UPS listed when you run cat /proc/bus/usb/devices?

Did you set both UPSCABLE and UPSTYPE values to usb and comment out the DEVICE line in your apcupsd.conf file?

Are you using a USB cable to communicate with your UPS?

Are all cables properly seated and/or UPS units powered on?If all the above are true and none of this helps, I'll need some more information about your system (UPS model, motherboard chipset, kernel configuration, etc.) in order to troubleshoot further...

----------

## Reducer2001

OK, I can see my UPS when I do a cat /proc/bus/usb/devices.  Here are the modules I have loaded:

```

cisco_ipsec           377792   0  (unused)

mousedev                3988   1

lp                      5792   0  (autoclean)

hid                    20196   0  (unused)

input                   3520   0  [mousedev hid]

usb-uhci               23216   0  (unused)

emu10k1-gp              1256   0  (unused)

gameport                1564   0  [emu10k1-gp]

orinoco_plx             2756   1

orinoco                35700   0  [orinoco_plx]

hermes                  5572   0  [orinoco_plx orinoco]

snd-pcm-oss            39108   1

snd-mixer-oss          13200   0  [snd-pcm-oss]

snd-seq-midi            3776   0  (autoclean) (unused)

snd-emu10k1-synth       4764   0  (autoclean) (unused)

snd-emux-synth         27804   0  (autoclean) [snd-emu10k1-synth]

snd-seq-midi-emul       5008   0  (autoclean) [snd-emux-synth]

snd-seq-virmidi         3128   0  (autoclean) [snd-emux-synth]

snd-emu10k1            74852   1  (autoclean) [snd-emu10k1-synth]

snd-pcm                64900   0  (autoclean) [snd-pcm-oss snd-emu10k1]

snd-rawmidi            14112   0  (autoclean) [snd-seq-midi snd-seq-virmidi snd-emu10k1]

snd-util-mem            1408   0  (autoclean) [snd-emux-synth snd-emu10k1]

snd-hwdep               4640   0  (autoclean) [snd-emu10k1]

snd-ac97-codec         43032   0  (autoclean) [snd-emu10k1]

snd-page-alloc          6100   0  (autoclean) [snd-emu10k1 snd-pcm]

snd-seq-oss            27360   0  (unused)

snd-seq-midi-event      3776   0  [snd-seq-midi snd-seq-virmidi snd-seq-oss]

snd-seq                40208   2  [snd-seq-midi snd-emux-synth snd-seq-midi-emul snd-seq-virmidi snd-seq-oss snd-seq-midi-event]

snd-timer              15396   0  [snd-pcm snd-seq]

snd-seq-device          4176   0  [snd-seq-midi snd-emu10k1-synth snd-emux-synth snd-emu10k1 snd-rawmidi snd-seq-oss snd-seq]

snd                    33860   0  [snd-pcm-oss snd-mixer-oss snd-seq-midi snd-emux-synth snd-seq-virmidi snd-emu10k1 snd-pcm snd-rawmidi snd-util-mem snd-hwdep snd-ac97-codec snd-seq-oss snd-seq-midi-event snd-seq snd-timer snd-seq-device]

soundcore               3972  10  [snd]

vfat                   10092   1  (autoclean)

fat                    31416   0  (autoclean) [vfat]

ntfs                   75564   1  (autoclean)

parport_pc             12836   1

parport                14272   1  [lp parport_pc]

nvidia               1629152  11

```

It is a standalone device.  Here's what I have compiled in for usb:

```

# USB support

#

CONFIG_USB=y

# CONFIG_USB_DEBUG is not set

CONFIG_USB_DEVICEFS=y

# CONFIG_USB_BANDWIDTH is not set

CONFIG_USB_EHCI_HCD=m

CONFIG_USB_UHCI=m

# CONFIG_USB_UHCI_ALT is not set

CONFIG_USB_OHCI=m

# CONFIG_USB_AUDIO is not set

# CONFIG_USB_EMI26 is not set

# CONFIG_USB_BLUETOOTH is not set

# CONFIG_USB_MIDI is not set

CONFIG_USB_STORAGE=y

CONFIG_USB_STORAGE_DEBUG=y

# CONFIG_USB_STORAGE_DATAFAB is not set

# CONFIG_USB_STORAGE_FREECOM is not set

# CONFIG_USB_STORAGE_ISD200 is not set

# CONFIG_USB_STORAGE_DPCM is not set

# CONFIG_USB_STORAGE_HP8200e is not set

CONFIG_USB_STORAGE_SDDR09=y

CONFIG_USB_STORAGE_SDDR55=y

# CONFIG_USB_STORAGE_JUMPSHOT is not set

# CONFIG_USB_ACM is not set

# CONFIG_USB_PRINTER is not set

CONFIG_USB_HID=m

CONFIG_USB_HIDINPUT=y

CONFIG_USB_HIDDEV=y

# CONFIG_USB_KBD is not set

# CONFIG_USB_MOUSE is not set

# CONFIG_USB_AIPTEK is not set

# CONFIG_USB_WACOM is not set

# CONFIG_USB_KBTAB is not set

# CONFIG_USB_POWERMATE is not set

CONFIG_USB_DC2XX=m

CONFIG_USB_MDC800=m

# CONFIG_USB_SCANNER is not set

# CONFIG_USB_MICROTEK is not set

# CONFIG_USB_HPUSBSCSI is not set

# CONFIG_USB_PEGASUS is not set

# CONFIG_USB_RTL8150 is not set

# CONFIG_USB_KAWETH is not set

# CONFIG_USB_CATC is not set

# CONFIG_USB_AX8817X is not set

# CONFIG_USB_CDCETHER is not set

# CONFIG_USB_USBNET is not set

# CONFIG_USB_USS720 is not set

```

My USB mouse works fine, and I working on getting my camera going.

Thanks for your help and the great HOWTO!

Jason

----------

## whiskeypriest

Okay...try uncommenting the DEVICE line in apcupsd.conf then restart apcupsd.  Remember to do:

```
# /etc/init.d/apcupsd zap
```

...since you didn't get a clean start from it.

In light of your existing USB mouse, you may need to do some tweaking of the DEVICE value if the default set during emerge doesn't work for you.  See this section of the apcupsd User's Manual for more details.

Meanwhile, other things you might consider...your kernel .config:

```
# USB support 

# 

CONFIG_USB=y
```

...versus mine:

```
# USB support 

# 

CONFIG_USB=m
```

Also, the relevant entries after running lsmod on my system look like the following:

```
Module                  Size  Used by    Tainted: P

hid                    16868   1

usb-ohci               19304   0  (unused)

sis900                 13516   1

usbcore                63948   1  [hid usb-ohci]
```

The fact that your hid entry comes up (unused) leads me to believe something's rotten in Denmark (no offense to any Danes, mind you).  Try recompiling your kernel with USB support as a module...

```
<M> Support for USB
```

...rather than built-in and see if that fixes the problem.  I can run with this as either a built-in or a module, but I recall reading somewhere that the module was preferred.

While you're in there, you may also try enabling 

```
<M>   UHCI Alternate Driver (JE) support
```

...since I noticed this was "not set" in your .config file.  I've read that some people have better luck with this than the main UHCI driver.  You've got all the other USB drivers built, one more can't hurt.

Are you running hotplug?  If not, you'll need to list the modules you want loaded in /etc/modules.autoload.d/kernel-2.4...I've always used hotplug so I can't really speak on this.

Finally, this is an APC-brand UPS, right?

NOTE: USB is not my area of expertise (assuming I have an area of expertise).  If you know for a fact that something needs to be "this way" in your kernel and I tell you to do otherwise, please be careful.   The last thing I want is someone trashing their system (losing mouse functionality, for example) on my account.  Make sure you've done a backup of everything pertinent.

Good luck, and let me know how it goes.

----------

## whiskeypriest

CHANGELOG:

Right...this bit me over the weekend, so I thought it was worth adding...

If you don't want to be locked out of your slave machine (for those of us running headless servers, etc.) as soon as apcupsd registers a power failure, be sure to add the NOLOGON parameter to your slave's apcupsd.conf file and set its value to disable.

Don't forget to restart apcupsd if you're making this change to an existing installation.

DOCUMENT EDITED TO REFLECT NEW SUGGESTED SLAVE CONFIGURATION PARAMETERS.

----------

## Reducer2001

Okay,  I did what you suggested:

```

#

# USB support

#

CONFIG_USB=m

# CONFIG_USB_DEBUG is not set

CONFIG_USB_DEVICEFS=y

# CONFIG_USB_BANDWIDTH is not set

CONFIG_USB_EHCI_HCD=m

CONFIG_USB_UHCI=m

CONFIG_USB_UHCI_ALT=m

CONFIG_USB_OHCI=m

# CONFIG_USB_AUDIO is not set

# CONFIG_USB_EMI26 is not set

# CONFIG_USB_BLUETOOTH is not set

# CONFIG_USB_MIDI is not set

CONFIG_USB_STORAGE=m

CONFIG_USB_STORAGE_DEBUG=y

# CONFIG_USB_STORAGE_DATAFAB is not set

# CONFIG_USB_STORAGE_FREECOM is not set

# CONFIG_USB_STORAGE_ISD200 is not set

# CONFIG_USB_STORAGE_DPCM is not set

# CONFIG_USB_STORAGE_HP8200e is not set

CONFIG_USB_STORAGE_SDDR09=y

CONFIG_USB_STORAGE_SDDR55=y

# CONFIG_USB_STORAGE_JUMPSHOT is not set

# CONFIG_USB_ACM is not set

# CONFIG_USB_PRINTER is not set

CONFIG_USB_HID=m

CONFIG_USB_HIDINPUT=y

CONFIG_USB_HIDDEV=y

# CONFIG_USB_KBD is not set

# CONFIG_USB_MOUSE is not set

# CONFIG_USB_AIPTEK is not set

# CONFIG_USB_WACOM is not set

# CONFIG_USB_KBTAB is not set

# CONFIG_USB_POWERMATE is not set

CONFIG_USB_DC2XX=m

CONFIG_USB_MDC800=m

# CONFIG_USB_SCANNER is not set

# CONFIG_USB_MICROTEK is not set

# CONFIG_USB_HPUSBSCSI is not set

# CONFIG_USB_PEGASUS is not set

# CONFIG_USB_RTL8150 is not set

# CONFIG_USB_KAWETH is not set

# CONFIG_USB_CATC is not set

# CONFIG_USB_AX8817X is not set

# CONFIG_USB_CDCETHER is not set

# CONFIG_USB_USBNET is not set

# CONFIG_USB_USS720 is not set

#

# USB Serial Converter support

#

# CONFIG_USB_SERIAL is not set

# CONFIG_USB_RIO500 is not set

# CONFIG_USB_AUERSWALD is not set

# CONFIG_USB_TIGL is not set

# CONFIG_USB_BRLVGER is not set

# CONFIG_USB_LCD is not set

```

Here's my lsmod:

```

Module                  Size  Used by    Tainted: P

cisco_ipsec           377792   0  (unused)

lp                      5792   0  (autoclean)

mousedev                3988   1

hid                    20228   0  (unused)

input                   3520   0  [mousedev hid]

uhci                   25980   0  (unused)

emu10k1-gp              1256   0  (unused)

gameport                1564   0  [emu10k1-gp]

orinoco_plx             2756   1

orinoco                35700   0  [orinoco_plx]

hermes                  5572   0  [orinoco_plx orinoco]

snd-pcm-oss            39108   0  (unused)

snd-mixer-oss          13200   1  [snd-pcm-oss]

snd-seq-midi            3776   0  (autoclean) (unused)

snd-emu10k1-synth       4764   0  (autoclean) (unused)

snd-emux-synth         27804   0  (autoclean) [snd-emu10k1-synth]

snd-seq-midi-emul       5008   0  (autoclean) [snd-emux-synth]

snd-seq-virmidi         3128   0  (autoclean) [snd-emux-synth]

snd-emu10k1            74852   1  (autoclean) [snd-emu10k1-synth]

snd-pcm                64900   0  (autoclean) [snd-pcm-oss snd-emu10k1]

snd-rawmidi            14112   0  (autoclean) [snd-seq-midi snd-seq-virmidi snd-emu10k1]

snd-util-mem            1408   0  (autoclean) [snd-emux-synth snd-emu10k1]

snd-hwdep               4640   0  (autoclean) [snd-emu10k1]

snd-ac97-codec         43032   0  (autoclean) [snd-emu10k1]

snd-page-alloc          6100   0  (autoclean) [snd-emu10k1 snd-pcm]

snd-seq-oss            27360   0  (unused)

snd-seq-midi-event      3776   0  [snd-seq-midi snd-seq-virmidi snd-seq-oss]

snd-seq                40208   2  [snd-seq-midi snd-emux-synth snd-seq-midi-emul snd-seq-virmidi snd-seq-oss snd-seq-midi-event]

snd-timer              15396   0  [snd-pcm snd-seq]

snd-seq-device          4176   0  [snd-seq-midi snd-emu10k1-synth snd-emux-synth snd-emu10k1 snd-rawmidi snd-seq-oss snd-seq]

snd                    33860   0  [snd-pcm-oss snd-mixer-oss snd-seq-midi snd-emux-synth snd-seq-virmidi snd-emu10k1 snd-pcm snd-rawmidi snd-util-mem snd-hwdep snd-ac97-codec snd-seq-oss snd-seq-midi-event snd-seq snd-timer snd-seq-device]

soundcore               3972  10  [snd]

usbcore                62348   1  [hid uhci]

vfat                   10092   1  (autoclean)

fat                    31416   0  (autoclean) [vfat]

ntfs                   75564   1  (autoclean)

parport_pc             12836   1

parport                14272   1  [lp parport_pc]

nvidia               1629152  11

```

I do have hotplug running as a service.  I also uncommented the DEVICE line in the .conf file.  Same error.

Thanks for you help thus far!!!

Jason

----------

## shakti

same issue here, mine stopped working after moving to 2.6 i think....

----------

## whiskeypriest

shakti:

Unfortunately, I can't help you with the 2.6 kernel...haven't messed with it at all, don't have it running anywhere, etc.  Read on, though...maybe something else here will help.

Reducer2001 (et al.):

I've actually been thinking about this one for the past few days; the fact that you can see your UPS in /proc/bus/usb/devices tends to preclude a problem with your kernel's USB support (I think) so the answer probably lies somewhere else.

Meanwhile, I booted into one of my Gentoo installation this evening and got the same error on startup:

```
apcupsd FATAL ERROR in linux-usb.c at line 684 

Cannot open UPS device:
```

After a moment spent wondering about spontaneous, contagious errors I remembered that this had happened to me once before...I knew that error looked familiar!  A quick glance at my USB hub (a D-Link DSB-H4) revealed that the port used by the UPS cable had no "active" LED indicator.  I ran:

```
 tail -f /var/log/messages
```

...then unplugged the USB cable from the hub and plugged it back in.  Presto!  The light came on, the tail spat up the stats on my UPS, and I was able to start apcupsd successfully.

I know I've read (I believe in the actual documentation that came with my APC UPS units) that these things shouldn't be plugged into hubs, but rather directly into a USB port on the machine they'll be supporting.  This may be an issue to consider.  I rebooted the machine several times in an effort to duplicate the error, but (unfortunately?) apcupsd started successfully each time.

Here's my thought: try examining your system logs while plugging and unplugging the USB cable to make sure it's being recognized.  Once you're certain this is the case, try starting apcupsd again.  If you're running a USB hub, try switching ports or moving to one directly mounted to the machine.

Failing all this, I'd double-check the apcupsd.conf file for errors.  Are both UPSCABLE and UPSTYPE set to usb?  I seem to recall instances where UPSTYPE was set to smartups or apcsmart on a standalone USB  configuration, but I can only get away with setting this value to usb.  Try changing the UPSTYPE values and restarting the daemon...maybe you'll get some results that way.

I hope something in here helps, because I'm running out of ideas.  If anyone else has any experience or insight to offer, please feel free to chime in...meanwhile, please keep me posted on your progress; also, the model of UPS you're using couldn't hurt.  We'll get this thing off the ground yet.

----------

## Reducer2001

I stopped the service, unplugged the UPS, plugged it back in, started the service, and voila!  It worked.  Even works on reboot.  Not sure why, it's plugged directly into my PC.

Thanks for your help whiskeypriest!

Jason

----------

## whiskeypriest

This is what happens when you forget your background in technical theatre; years and years of being told "check the cables first" and what's the last thing I think of?

I also have no good explanation as to why this happens (on the rare occasions it does, at least in my case).  At least the solution's there the next time this particular issue arises.

In any case, I'm glad to hear it's working for you now.  Let me know if there are any further problems...

----------

## shakti

just want to say it just started to work after i upgraded to 2.6.3 kernel, I guess i had an usb issue ...

----------

## whiskeypriest

Also very good news.  Glad it's working.

Any idea where the sticking point was so I can advise other users, or was USB support just "off" in the earlier version of 2.6?

----------

## shakti

i used the same .config so it must have been an kernel issue....

----------

## whiskeypriest

Thanks for the reply, shakti.

CHANGELOG:

DOCUMENT EDITED TO REFLECT POTENTIAL USB ISSUE AS OUTLINED IN THE POSTS ABOVE.

----------

## GTVincent

I got it all up and working by following these instructions (thanks! :Smile: ), but after a certain amount of time my computer hangs. Would anyone know a fix/workaround for that?

----------

## GTVincent

 *GTVincent wrote:*   

> I got it all up and working by following these instructions (thanks!), but after a certain amount of time my computer hangs. Would anyone know a fix/workaround for that?

 

Hm... I rebuilt my kernel with the ACPI battery module, which was turned off before. It may have done the trick. It's been up and running all night without a problem. I'll be keeping an eye on it though:)

----------

## whiskeypriest

Always nice to find an issue resolved before you've had a chance to get to it.  Hopefully things will remain stable for you.

Ive enabled ACPI support without the battery module on both VIA and SiS chipsets without issue; for posterity's sake, would you mind providing some more details on your issue?Which version of apcupsd are you using?  Which kernel?

What sort of motherboard are you using?

Is this a laptop or a desktop?  I ask since the battery module solution seems unusual for a desktop...

Where, exactly, did your system hang  did your desktop environment freeze, did you lose keyboard response completely, or?

Did your logs provide you with any information regarding the cause of this behavior?

What led you to believe enabling the battery module was the solution?

Is there anything else youre running/using/etc. which might explain this behavior?Again, Im just trying to lock down where the issue is in order to assist others who might be experiencing the same thingthanks for keeping me posted.

----------

## GTVincent

 *whiskeypriest wrote:*   

> Always nice to find an issue resolved before you've had a chance to get to it.  Hopefully things will remain stable for you.
> 
> Ive enabled ACPI support without the battery module on both VIA and SiS chipsets without issue; for posterity's sake, would you mind providing some more details on your issue?Which version of apcupsd are you using?  Which kernel?

 

apcupsd 3.10.10 on a 2.6.3 kernel (I know... I read your kernel disclaimer  :Wink:  )

 *Quote:*   

> What sort of motherboard are you using?

 

Asus A7N8X Deluxe (nforce2), with two SATA drives in a normal mode, no RAID.

 *Quote:*   

> Is this a laptop or a desktop?  I ask since the battery module solution seems unusual for a desktop...

 

It's a desktop. I'm not sure that adding the battery module actually did anything. It's not being loaded anyway. Other ACPI modules aren't being loaded by default either. Could it be that when the UPS reports a power failure, some ACPI modules will be loaded, which might cause instability? Would it make sense to use a kernel acpi option? I see mention of noacpi or acpi=off in some posts, but wouldn't that basically mean that apcupsd couldn't work?

 *Quote:*   

> Where, exactly, did your system hang  did your desktop environment freeze, did you lose keyboard response completely, or?

 

The system just hung. It's a router and file server that doesn't run any desktop, it just routes and serves. It stopped routing and serving altogether when it happened. When it's gotten in that state I can't type on the machine's keyboard itself, and I can't ssh into it anymore. It's just become a dead weight (or a very expensive paper weight...).

 *Quote:*   

> Did your logs provide you with any information regarding the cause of this behavior?

 

Nope, the logs don't tell me anything other than that the power has failed (which it hasn't...) for one second. I've had one hang since I wrote the second post, but that one occured some 10+ hours after the second (fake) power failure message I found in the log. That would indicate that the power failure in itself is not directly causing my system to hang. Besides, before I recompiled my kernel, it would hang after ten minutes of uptime (while weeks on end, until I upgrade the kernel, is it's usual uptime), even though there was no mention of anything at all in the apcupsd log, let alone of power failure.

 *Quote:*   

> What led you to believe enabling the battery module was the solution?

 

Nothing really. Only that it was the only ACPI option that wasn't build as a module and that after I had set it to compile as a module and rebuild the whole kernel, it worked. It was the only kernel config change that I made. Another (possible) difference could be that the previous 2.6.3 kernel was compiled with a slightly older version of gcc. This one was compiled using 3.3.2.

 *Quote:*   

> Is there anything else youre running/using/etc. which might explain this behavior?

 

No, and the only thing I changed was emerge hotplug and apcpusd and rc-update them to default.

 *Quote:*   

> Again, Im just trying to lock down where the issue is in order to assist others who might be experiencing the same thingthanks for keeping me posted.

 

No problem. If you have anything else you want me to look into, feel free to ask:)

----------

## whiskeypriest

First off, thanks for the additional information.

If I understand you correctly, your current situation is as follows:After you initially recompiled your kernel per the above HOWTO, your system became unresponsive after ten minutes of uptime.

Recompiling the kernel with the addition of the ACPI Battery module seems to have alleviated the problem, though youve experienced one more instance of system unresponsiveness since then.

ACPI modules are not being loaded at runtime.

You have one instance of a power-failure notification in your logs, but the apcupsd log does not corroborate this power failure.Assuming the above, I have a few more questions:If the power-failure notification didnt appear in the apcupsd log, where did it appear?  Any possibility this was related to the apcupsd tests you might have run during the initial configuration?

Did your previous (i.e. pre-apcupsd modifications) kernel have ACPI support enabled?  If not, did it have any power management support enabled?  If it had non-ACPI power management, what was it?

What model of APC UPS are you running?  Are you confident its in good working order?

Do you have SMP support enabled in your kernel?  If so, do you actually need it?Ill give the standard disclaimers about my working knowledge of these subjects, but at first blush your problems might be attributable to one of the following.  Theyre in descending order by how likely I believe them to be:

ACPI:

 *GTVincent wrote:*   

> I see mention of noacpi or acpi=off in some posts, but wouldn't that basically mean that apcupsd couldn't work?

 

Actually, its my understanding that this is not the caseall apcupsd does is call the shutdown; what your machine does after that depends on its power management support.  I can run apcupsd without any sort of power management enabled; all that will happen on shutdown is that the system will halt itself without powering down, i.e. youll be left staring at the Power down. message on your terminal while the system waits for you to manually kill the mains.  All your hard drives will be safely halted, services shut down, etc.

If youre running a headless server, this might be a viable workaround for youjust recompile without the ACPI support and see if that resolves the system hangs.  If it does, at least we know where the problem lies.

To take this to its logical conclusion, if you had your system configured to power itself down on shutdown previous to implementing this HOWTO, put it back like it was.  The ACPI/APM sections of the HOWTO are simply rough sketches of how to enable this functionality if you didnt have it alreadyif it was already working, stick with your previous configuration.

One final note: I asked about the SMP support in your kernel because Ive read that ACPI has problems playing nicely with it.  If youre not running multiple processors or a P4 with HT, you should try removing this option in your kernel; you might try it regardless in the latter case.  

apcupsd:

Its possible that the system hangs youre experiencing are actually system halts ordered by apcupsd, though I find this unlikely as you would have seen evidence of it in your logs.  In my experience, apcupsd is very good about reporting any power events to both its log and the system log; if youre not seeing anything here, Im willing to bet apcupsd isnt the problem.

Double-check your apcupsd.conf file (especially the TIMEOUT value, which should be 0) if you think this might be where the snag is.

BAD UPS UNIT/CABLE:

Least likely of all, but never to be underestimated.  If you have any doubts about the battery, cable, etc. try swapping them out or connecting them to other machines (if possible) to make sure everythings functioning properly.

I hope something here solves your problem (or at least narrows the scope on it).  Ive got one of the new 2004.0 LiveCDs on deck for a test installation sometime in the next few dayshopefully, Ill be able to remove that 2.6.x disclaimer from this HOWTO by next week.

Good luck, and please let me know how it goes

----------

## GTVincent

 *whiskeypriest wrote:*   

> If I understand you correctly, your current situation is as follows:After you initially recompiled your kernel per the above HOWTO, your system became unresponsive after ten minutes of uptime.

 

I didn't recompile my kernel before emerging hotplug/apcupsd. When I had emerged both, it was, if I recall correctly, about an hour before a power failure, that I did NOT notice on any of my other systems that I was working on at that same time, allegedly made my system unresponsive. After that, the system would indeed flake out on me after ten minutes of uptime. At least three times without any mention of anything going wrong in any system log and also not in the apcupsd log. That's when I added the ACPI Battery module to my kernel and recompiled both kernel and modules, rebooted and it stayed up for almost a day (24 hours) before it became unresponsive

 *Quote:*   

> Recompiling the kernel with the addition of the ACPI Battery module seems to have alleviated the problem, though youve experienced one more instance of system unresponsiveness since then.

 

Correct

 *Quote:*   

> ACPI modules are not being loaded at runtime.

 

Correct. When I shutdown, however, right before it says Power Down, I can see an ACPI message, I assume that is the button module being loaded to perform the shut down.

 *Quote:*   

> You have one instance of a power-failure notification in your logs, but the apcupsd log does not corroborate this power failure.

 

In my apcupsd log there are now two mentions of a power failure. One that I for sure know it wasn't a 'real' failure, since no other computers were bothered by it while I was working on them. This power failure happened about an hour before the system stopped responding. The other alleged power failure that the apcupsd log mentions was while I wasn't there, but I found no evidence of the failure on my microwave, oven, clocks, etc. This second power failure occurerd while I had my recompiled (with the Battery module) kernel running. The system did not become unresponsive right away but some 10 or 11 hours later.

 *Quote:*   

> Assuming the above, I have a few more questions:If the power-failure notification didnt appear in the apcupsd log, where did it appear?  Any possibility this was related to the apcupsd tests you might have run during the initial configuration?

 

It did appear in the acpusd log. I haven't had the time to run any tests yet. Currently I have disabled the hotplug and apcuspd services because I unfortunately do not have time to look into it.

 *Quote:*   

> Did your previous (i.e. pre-apcupsd modifications) kernel have ACPI support enabled?  If not, did it have any power management support enabled?  If it had non-ACPI power management, what was it?

 

Yes, it had all ACPI modules but the one for Battery installed 

 *Quote:*   

> What model of APC UPS are you running?  Are you confident its in good working order?

 

It's a CS725BB that I had bought just two days ago. Again, I don't have time (yet) to verify that it's the computer/software that is causing this problem or the UPS itself. I hear that nforce2 and ACPI aren't necessarily a good combination. It may very well be due to that.

 *Quote:*   

> Do you have SMP support enabled in your kernel?  If so, do you actually need it?

 

No, SMP support is not enabled. There is an Athlon XP-3000+ on the motherboard which I don't believe does hyperthreading.

 *Quote:*   

> [ Cut out lots of good advice and tips that I will surely try out at one point or another, thanks  ]
> 
> I hope something here solves your problem (or at least narrows the scope on it).  Ive got one of the new 2004.0 LiveCDs on deck for a test installation sometime in the next few dayshopefully, Ill be able to remove that 2.6.x disclaimer from this HOWTO by next week.

 

I bet you'll love the 2.6.x kernel. If I can avoid it I'll never look back! Thanks for your support, and if you still have more questions, feel free to ask. If you're afraid we'll go too specific for the forums, you can also send me a personal message  :Wink: 

----------

## whiskeypriest

GTVincent:

Not that it's necessarily any comfort to you, but I've been running the latest development-sources (2.6.4-rc1) for approximately 24 hours now without incident.  FluxBox is on the desktop, GkrellM is humming away, Opera is open on my apcupsd status page, and XMMS has been playing non-stop the entire time.  No changes to the kernel configuration outlined above were necessary: ACPI is still built-in and only Button and Processor have been enabled as modules.  Again, this is a SiS chipset, so it may not do you much good.

However...

I did hit my head on one thing before the *NIX state of grace returned.  The above HOWTO was written before apcupsd-3.10.10 hit Portage; it seems there's a problem in the /etc/apcupsd/apccontrol file installed by the latest version, right around line 89:

```
mainsback)

   echo "Power has returned on UPS ${2}..." | wall

   if [ -f /etc/apcupsd/powerfail ] ; then

      printf "Continuing with shutdown."  | wall

   fi

   ;;

;;
```

The redundant ;; resulted in a lot of error messages when I went to test apcupsd and completely prevented the system from shutting down, i.e. my logs showed that a shutdown had been initiated, but the system remained operational (and very much not shut down).

After editing the relevant section of the apccontrol file to the following:

```
mainsback)

   echo "Power has returned on UPS ${2}..." | wall

   if [ -f /etc/apcupsd/powerfail ] ; then

      printf "Continuing with shutdown."  | wall

   fi

;;
```

...everything works as expected (at least for the past day or so).  Perhaps this will help you when you get a chance to mess with it again.

For everyone else reading this who's upgraded from an earlier version of apcupsd to version 3.10.10, you will not be warned about this until apcupsd needs to take an action (e.g. your system loses power, loses communication with its UPS, and so on).  Neither etc-update nor cfg-update (which I adore, by the way) caught this on the update, so consider yourselves warned...and yes, I know apcupsd-3.10.10 has been out for a few weeks now.  After a clean upgrade and .conf update, I didn't think I needed to run the tests again either...

CHANGELOG:

See above.  Also qualified the 2.6 kernel disclaimer, since it seems I've been able to get apcupsd running with little difficulty.

DOCUMENT EDITED TO REFLECT NECESSARY EDITING OF THE APCCONTROL FILE IN VERSION 3.10.10.

----------

## GTVincent

At the risk of jinxing things: Since I removed the ;;'s after your last post, I've seentwo reports of power failure in the logs on March 9th, but this morning the machine was still responding and working as expected. I have no idea what the cause for last week's hangs is. But (knock on wood) it's working now.

Thanks to WP for his patience and support  :Smile: 

----------

## whiskeypriest

Hope it remains stable for you...as stated above, that one redundant ";;" resulted in some seriously undesirable behavior on my systems.

As for your phantom outages: I'm no expert, but I have observed that some systems are more resilient than others when it comes to minor line fluctuations.  There have been several occasions where my archaic Celeron-VIA-P.O.S. was still running after a brief power drop, while my modern P4-SiS workstation had rebooted itself...

----------

## GTVincent

 *whiskeypriest wrote:*   

> Hope it remains stable for you...as stated above, that one redundant ";;" resulted in some seriously undesirable behavior on my systems.
> 
> 

 

I think I found the actual cause of my problems. It turns out that the SATA drive containing the root of my installation  is on it's way to bit-heaven  :Sad:  It rest in pieces and shall be RMA'd in the very near future.

In the mean time I've set up another computer as my router, gave it the UPS and I haven't had a problem with that one.

Yet  :Wink: 

----------

## t0mcat

i'm having a different hang problem:

it happened two times, during rainy days, that, as usual where i live, there was a very quick lights-off-lights-on.

Theese two times it happened, the UPS (APC RS 800) did his work, but the pc crashed, the mouse freezed, no keys responding, and the keyboard leds blinking like an on-boot kernel panic.

the UPS works good with long blackouts, it correctly shutdown the system, but when occurs one of thoose nanosec energy failure, the PC hangs.

i've no stuff in every log of my pc, the failure is not reported in apcupsd log neither elsewhere, the kern.log appears like just deleted (but the old one stored by syslog-ng is 1 day old), there is no error reported in any other log, they are just interrupted.

the sys config is in the sign.

i've correctly followed the how-to, and corrected the apccontrol redundant ;;.

i've just recompiled the kernel with acpi battery as module (the other ACPI options are built-in, shall i recompile them as modules?), i'll see if the problem occurs again (but i guess i must wait another rainy day  :Razz:  ).

i'm running also other services like apache, proftpd and postfix, but i don't think they are related to the problem.

hope my english is understandable

----------

## shakti

a rapid on off of the power should not matter as the ups delays a bit before coming back on mains. Maybe adjust the sensitivity of you ups:

in /etc/apcupsd/apcupsd.conf:

```

#    D 106 103 100 097

#    M 177 172 168 182

#    A 092 090 088 086

#    I 208 204 200 196     (default = 0 => not valid)

LOTRANSFER  208 #set this to something higher Italy is 220? go for 208

WAKEUP 60 #wait 1 minute before coming back online

SENSITIVITY H

```

----------

## whiskeypriest

t0mcat:

I believe shaktis got it rightit sounds as though apcupsd is trying to call the poweroff/mains-back events without enough delay between the two.  The UPS itself should do a fine job of providing power through these brief outages without getting apcupsd involved  this is exactly what I bought my UPS units for, as brief drops are far more common in my area than extended outages.  Im not in front of my machines to check my settings at the moment, but it usually takes apcupsd about ten-to-fifteen seconds to acknowledge a power failure and a like amount of time to acknowledge a return to the mains.  Following shaktis recommendations should solve your problem.

Also, you may want to double-check the TIMEOUT value in your apcupsd.conf file, just to be certain it was reset to 0 after testinganything else may be causing a premature shutdown-call that your machine is having difficulty recovering from.

Finally, if you want to test this theory without the rainy-day vector, you might try the time-honored tradition of breaker-off/breaker-on (if you have access to such things for your domicile).  Failing that, theres always the plugplease post here if you get the problem satisfactorily resolved.

shakti:

Thanks for the quick response on this.  Im actually in the midst of installing a poor-mans access floor in my main computer room, and as such only have sporadic access to my email currently

----------

## t0mcat

mmm, that was strange:

i've changed sens from H to M.

when i've restarted APCUPSD i've got the same crash!

i had to reboot, as usual, with a total shutdown (reset didn't worked).

now i have apcupsd running with sens M. i've tried a fast plug-off-plug-on with the power switch, and it seems to be ok, but i think that a rainy day will be a more realistic test.

i'll report it as soon as it will come!

----------

## whiskeypriest

Just a quick update: I noticed apcupsd-3.10.10-r1 in portage earlier today, and have upgraded/tested all installations without incident.

Remember not to overwrite your apcupsd.conf file and you should be fine.

----------

## mazirian

I, on the other hand, was not able to update easily:

```

tardis root # /etc/init.d/apcupsd start

 * Starting APC UPS daemon...

start-stop-daemon: stat /usr/sbin/apcupsd: No such file or directory     [ !! ]

```

Oops. Where'd the executable go?

----------

## mazirian

Oh, I see it's a bug already

46354

----------

## mazirian

..and now the ebuild is fixed.

Ok, sorry, nevermind me, just passing through.  Nothing to see here...

----------

## whiskeypriest

Again, it's always nice when these things resolve themselves before I've even read the post...let me know if anyone runs into any further difficulties with this release.

----------

## whiskeypriest

Found apcupsd-3.10.10-r2 in portage just now; upgrade/testing ran normally on all systems.

----------

## shanenin

thanks alot for the "how to" . It is nice being able to read a nice doc while trying to set something up, no need for endless searching. I had it setup, including a new kernel recompile in about 1/2 -1 hour.

edit/added

my alarm is not going off, which I guess is not all that important. If I read my apcupsd.conf correctly it should be going off immediatley after powerfaliure(default setting). The alarm is working when I have windows booted(hardly ever).. Maybe something is set wrong in my apcupsd.conf .

If it matters, I am running 2.6.4 . During the kernel config i think I followed all of your options exactly, except all of my usb modules are compiled directly into the kernel.

----------

## shanenin

I am happy enough with my ups behavior, but not totally. Below is a section from my apcupsd.conf

```

# Low line voltage causing transfer to batteries

# The permitted values depend on your model as defined by last letter 

#  of FIRMWARE or APCMODEL. Some representative values are:

#    D 106 103 100 097

#    M 177 172 168 182

#    A 092 090 088 086

#    I 208 204 200 196     (default = 0 => not valid)

LOTRANSFER 97  

#

# High line voltage causing transfer to batteries

# The permitted values depend on your model as defined by last letter 

#  of FIRMWARE or APCMODEL. Some representative values are:

#    D 127 130 133 136

#    M 229 234 239 224

#    A 108 110 112 114

#    I 253 257 261 265     (default = 0 => not valid)

HITRANSFER 136
```

It does not seem to have any effect on my results in apcaccess status if I uncomment the high and low tolerence settings for voltage. The figures that are shown in apcaccess status are the same ones that I set when I was running my ups in windows.

----------

## whiskeypriest

Interesting.  I've never had any issues with my UPS alarms (both chirp at me on a regular basis this time of year) but then, it also appears you're down in the EEPROM section of apcupsd.conf (which I routinely leave commented out).

The reason for this is twofold: one, neither of my UPS units (a Back-UPS CS350 and a Back-UPS XS1000) support EEPROM programming from apcupsd.  If I run the appropriate command to check for the EEPROM output:

```
# apcaccess eeprom

FATAL ERROR in apcaccess.c at line 225

Your model does not support EPROM programming.
```

The second reason I don't touch this stuff is because it seems to be vestigial in apcupsd-3.10.10-x; according to the apcupsd Users Manual apcupsd.conf no longer configures the EEPROM (unless you choose to have it do so specifically from the appropriate utility).  I won't go into the process for this as it's well very documented here...but I will draw your attention to the following from the aforementioned page:

 *Quote:*   

> In general, for the moment, we do not recommend that you change your EEPROM values unless absolutely necessary. There have been several reported cases of problems setting the Low Transfer Voltage. Consequently, if at all possible, do not attempt to change this value.
> 
> If despite these warnings, you must change your EEPROM, we recommend connecting your UPS to a Windows or NT machine running PowerChute and making the changes.

 

So while I can't explain your lack of alarm (though I'd start by commenting out the BEEPSTATE line and see where that gets you) your problems may stem from the fact that either you don't have a UPS that supports EEPROM programming, or you haven't used the correct command to update the EEPROM.  This would also explain why your values haven't changed from where you set them while using PowerChute under your Windows installation.

Hope this goes some way towards answering your questions on this; EEPROM programming is not something I'm horribly familiar with (because my UPS units don't support it) so I'd be interested to hear what you come up with.  

Best of luck, and glad the rest of the HOWTO was of use to you...

----------

## shanenin

```
shane@marsala shane $ /usr/sbin/apcaccess eeprom

FATAL ERROR in apcaccess.c at line 225

Your model does not support EPROM programming
```

mine must not support eeprom either. To be honest I do not understand what eeprom is. Is it to do with the settings in the lower part of my apcupsd.conf? 

Thanks for the link to the manual, I am sure I will find some answers there.

----------

## whiskeypriest

From en.wikipedia.org, because I wasn't entirely sure myself:

 *Quote:*   

> An EEPROM, or Electrically-Erasable Programmable Read-Only Memory, is a non-volatile storage chip used in computers and other devices. Unlike an EPROM, an EEPROM can be programmed and erased multiple times electrically. It may be erased and reprogrammed only a certain number of times, ranging from 100,000 to 1,000,000, but it can be read an unlimited number of times. Flash memory is a later form of EEPROM. In the industry, there is a convention to reserve the term EEPROM to byte-wise writable memories compared to block-wise writable flash memories. EEPROM takes more die area than flash memory for the same capacity because each cell usually needs both a read and a write transistor where flash memory needs only one.

 

What does this mean to us?  Not much, beyond what I mentioned earlier.  You're correct that the EEPROM settings are (or rather, were) configured in the last section of your apcupsd.conf file.  Since this functionality has been transferred to the apctest utility, those lines at the bottom of apcupsd.conf have essentially become superfluous, which (I'd imagine) is why they're commented out in the default configuration.

All of which is a moot point since I can't program the thing with apcupsd anyway.  Personally, I make sure there's a nice # in front of every line from...

```
# ========== Configuration statements used in updating the UPS EPROM ==========
```

...to the end of the apcupsd.conf file.  Since my UPS units do not support this functionality, it's my preference to leave everything pertaining to it out of the configuration apcupsd uses.  

Try it, restart apcupsd and see if your alarm is functioning as expected.  If your particular situation absolutely requires tweaking of the EEPROM, I'd take the manual's advice and do it from your Windows installation.  Just my $0.02  again, this isn't something I'm familiar with, so I'd be interested in what you find...and if someone else with more expertise on the brainstem functions of the APC UPS wants to weigh in here, please feel free.

----------

## bruor

im still getting a problem that was mentioned earlier on. 

```
 # /etc/init.d/apcupsd start

 * Starting APC UPS daemon...

start-stop-daemon: stat /usr/sbin/apcupsd: No such file or directory      [ !! ]
```

i have tried an unmerge/remerge,  as well as 10.9, (currenctly 10.10-r2)  even tried 10.13 

i always get this compile error. 

```
gcc -g -O  apcupsd.o apcoptd.o apcnet.o apcreports.o apcaction.o apcnis.o apcdevice.o /var/tmp/portage/apcupsd-3.10.10-r2/work/apcupsd-3.10.10/src/drivers/libdrivers.a /var/tmp/portage/apcupsd-3.10.10-r2/work/apcupsd-3.10.10/src/lib/libapc.a  -lpthread    -o apcupsd

apcupsd.o(.text+0x33f): In function `main':

: undefined reference to `attach_driver'

collect2: ld returned 1 exit status

gmake[1]: *** [apcupsd] Error 1

```

but the emerge reports success for every version,  if anyone has an idea of whats going on that would be great,   else if someone wants to just give me a link to the already built file,  im sure itll run no problem  :Wink: 

----------

## whiskeypriest

Ive been researching your problem for the past few days, and besides this thread (which youve already found) Ive come up completely empty.

I hate to raise the ugly specter of remerging glibc, and gcc, but are your versions up-to-date?  Have you recompiled glibc against the latest kernel-headers?  Please keep in mind Im not advocating this, just taking the proverbial shot in the dark.

I also noticed that your most recent post (to the aforementioned thread) mentions a few USB-related issues while compiling.  Could this be a problem with your kernel configuration or USE flags?  Again, just guessing

If anyone else has any experience with or solution to this problem, please feel free to chime inIm buffaloed.

----------

## bruor

thanks for your response,  im using gentoo-dev-sources 2.6.5,  bttv is broken in 2.6.7,  as far as mythtv goes anyway.  linux-headers is a matching version, as well the linux26-headers do not compile for me. 

i did re-merge glibc just in case that would have an effect,  as well,  they are all up to date _stable_ releases.   only use flags effecting the build are usb and apache2,  snmp is off by default. 

on a side note,  i had a frien emerge -OK apcupsd-10.13 for me,  i got the bzip2 and i untarred it in  /     

all the files i needed are now there,  and apcupsd is working properly.  im hoping after a few versions of other things get changed that stuff will work a little better.   let me know if you uncover anything  :Wink: 

thanks again.

----------

## webnoelle

great guide  :Smile:  worked great for me!! thnx!!

----------

## whiskeypriest

bruor:

Sorry for the late reply; Ive been on the road and my access has been sporadic, to say the least.  Ill post here if I find something relevantmeanwhile, I hope the next iteration of apcupsd treats you better.

webnoelle:

Glad you found it useful!

----------

## bruor

thanks for the reply,  i think after some other stuff out there gets updated an emerge -u world will resolve some things  fi i find a finite solution ill post it here.

----------

## whiskeypriest

As of earlier today, apcupsd-3.10.13 is available in portage.

All installations updated/tested without incident.

----------

## elpierco

So I had to compile usb support directly into the kernel to get the APC to work.  I am using a 2.6 kernel...the guide is for 2.4 if I am not mistaken.  So my question is anyone get the web application to work so that you can log into the web and check on the status???  Thanks El

----------

## whiskeypriest

I have the same USB configuration (built in, not modular) for my 2.6 kernels; updating the HOWTO for 2.6-specific options is on my list, it simply hasn't been implemented yet.

Meanwhile, exactly what problems are you encountering with the UPS Network Monitor?  I'll need more information to assist you, but here's the short list of possible difficulties:Do you have Apache installed on the machine that will be monitoring your UPS unit(s)?

If so, did you restart both apcupsd and Apache after you completed the installation?

If not, you'll need to emerge Apache and remerge apcupsd.  Remember to back up your apcupsd configuration files!

Did you modify /etc/apcupsd/hosts.conf to reflect your particular network configuration and restart apcupsd afterwards?

Are you directing your browser to the correct address?I realize some of these fall under the “stupid question” category, but it never hurts to establish a baseline, especially (say) if you're running a customized Apache configuration (e.g. documents stored somewhere besides /var/www/).Last edited by whiskeypriest on Sat Aug 28, 2004 4:09 am; edited 1 time in total

----------

## elpierco

So I found the cgi scripts and go them setup...I just asked before searching around   :Embarassed: 

Thanks for that quick response...I did a little test with my Back-UPS 500 ie 500VA(volt amps)

I unplugged it from the wall and is started beeping...it said I had about 11 minutes of run time and the load was about 47%.   So I multiplied that load by 500VA and that gave me 235VA.  I then divided that by what my line voltage was being reported as 124V and the amperage that my box is drawing...1.89A.  Of course this is a system totally idle.  P4 2.8GHz@800MHz FSB with 6 SATA disks and an ide disk(the root disk) .  I am in kansas and we have had some crazy storms the past week.  It is actually storming out right now and thus why I decided to get the APC.  For some reason I have the horrible image of all the read heads on my disks crashing to a sudden halt when we lost power the other night (before the APC).   Anyway thanks again...El

----------

## suhlhorn

Excellent HOW-TO!

Most everything went smoothly on the setup; just a couple of comments:

1) I had problems building usb support as a module with my 2.6 kernel. After making usb built-in, everything went smoothly.

2) The UPS unit does not appear to shut off via the 'killpower' option to apccontrol after the shutdown sequence has completed. Is this a limitation of my UPS (APC Back-Ups RS 1000) or a problem with the shutdown/halt scripts?

I waited a good 6 mins after the host shutdown for the UPS to 'killpower', but I had to turn it off by pressing the UPS power button. I'm assuming this has to happen for the UPS to correctly bring the computers back up when AC power returns.

UPDATE: I just noticed that the halt script looks for /etc/apcupsd/powerfail in order to killpower to the UPS. I just did a quick test and the file is not created when there is a loss of power. Looking through the apcupsd manual, it looks this should be taken care of by the /etc/apcupsd/poweroff or onbattery script:

http://www2.apcupsd.com/3.10.x-manual/shutdown.html

Any thoughts?

-stephen

----------

## whiskeypriest

CHANGELOG:

suhlhorn:

Thanks for the feedback...you're the second person to comment on the 2.6 USB configuration, which finally motivated me to enter those into the main document.

As for your second concern, that's an excellent question: see the new Troubleshooting apcupsd with USB thread for my musings (though not answers, unfortunately) on the subject, and please accept my apologies for the sudden change in venue...

DOCUMENT EDITED TO REFLECT NEW SUGGESTED 2.4 AND 2.6 KERNEL CONFIGURATION PARAMETERS, LINKS INCLUDED TO THE NEW TROUBLESHOOTING THREAD.

----------

## LodBot

Awesome guide!  I do have one questions, though.  How can I get my APC unit to turn my machine back on when power is restored?  Right now, when the APC shuts down my system, gentoo hangs on the "Power Down" step of the shut down process.  It doesn't actually power down.  I guess what I'm asking is how can I get gentoo to shutdown without having to push the power button?  I changed my BIOS last state setting so my system should turn back on when power is restored.

Thanks in advance.

----------

## whiskeypriest

Thanks for the feedback, and Im glad you found the guide useful.  Ive posted a reply to your questions in the Troubleshooting apcupsd with USB threadplease have a look there.

----------

## signal11

Thanks for a beautifully written guide. Everything "just works" (TM). I am using the latest and greatest kernel 2.6.8.1, without any problems. The only minor issue is that for some reason, my LINEV is forever set at 000.0   :Sad: . Googling / looking at the apcupsd mailing lists/manuals etc. didn't provide with much info.

Any ideas ?

----------

## whiskeypriest

Thanks for the kind words.

I have the same issue, but only on some units: my Back-UPS XS 800's do not report line voltage, while my Back-UPS RS 1000 does.  So far as I'm aware, this is simply a limitation of the individual models and not a problem with apcupsd itself.

If you have any other questions or find information to the contrary, please post in the Troubleshooting apcupsd with USB thread.  I'll add any new findings to the main document.

Meanwhile, enjoy!

----------

## ectospasm

I also found the guide tremendously useful.  You can mark that this guide also works for AMD64 machines (I have a dual-Opteron setup), and I haven't had any problems.  I have model Back-UPS RS 1500, with optional Back-UPS RS/XS 1500 battery pack.  I'm running kernel 2.6.7-gentoo-r11 (2.8.x has issues with VFAT support), and I always compile everything into the kernel (no modules except NVidia).  I'm running it in the standalone configuration.  

All I need to do now is tweak the configuration, because during the final test, the battery was >5% and the time left was >3min, and it still shutdown.  I had maybe 10-20min before it shutdown (I believe it was ~80% and ~75min left).  Not a huge problem, just a minor annoyance.  The other annoyance is related to the ANNOY settings:  whenever the power glitches or I lose power totally, every terminal window receives the broadcast messages from root saying that power has failed and I'm running on battery, and also for when power is restored.  I don't want to totally disable the messages, but they are what they're labeled, an annoyance.

A great HOWTO, thanks so much for writing it.

----------

## whiskeypriest

CHANGELOG:

ectospasm:

Thanks for the information (especially regarding the AMD64 functionality).  Ive posted a (slightly) more detailed reply in the Troubleshooting apcupsd with USB thread regarding your shutdown issue; as for the annoying ANNOY messages, yeah, theyre either annoying or not thereits ultimately up to the users discretion.

DOCUMENT EDITED TO INCLUDE THE FIRST (REPORTED) INSTANCE OF THIS HOWTO BEING SUCCESSFULLY UTILIZED ON AMD64 HARDWARE; ADDED CAVEAT REGARDING POWER MANAGEMENT; ADDED NOTES ON MISCELLANEOUS FUNCTIONALITY SECTION.

----------

## whiskeypriest

Upgraded to apcupsd-3.10.15-r1 last night; spent this afternoon running full power failure tests (as opposed to abbreviated TIMEOUT tests) in light of recent developments on the troubleshooting thread.  All went without incident and performed as expected.

I'm also going to begin listing the system specifications, kernel versions, and UPS models I test with here for an added degree of granularity should troubleshooting become necessary.  The follow performed fine with the latest stable version of apcupsd:P4 2.53GHz, SiS chipset, gentoo-dev-sources-2.6.9-r1, Back-UPS XS 800, standalone configuration.

P3 600MHz, Intel chipset, gentoo-dev-sources-2.6.9-r1, Back-UPS XS 800, standalone configuration.

Celeron 733MHz, Intel chipset, gentoo-sources-2.4.26-r9, Back-UPS RS 1000, netmaster configuration.

Celeron 533MHz, VIA chipset, gentoo-sources-2.4.26-r9, Back-UPS RS 1000, netslave configuration.Please post any problems to the Troubleshooting apcupsd with USB thread.

----------

## whiskeypriest

CHANGELOG:

Thanks go to ectospasm for providing the information which now makes up the new CALIBRATION section of the main document.

ADDED CALIBRATION SECTION.

----------

## aaronjb

Just wanted to say thanks for an excellent HOW-TO  :Smile: 

My SmartUPS 750 arrived today, so after spending all day drilling holes in walls and moving the servers into a big cupboard it was so nice to have something go really smoothly  :Wink: 

In fact, all I did was skip the USB parts (I'm old school, so it's RS232 all the way for me.. plus I was feeling too damned lazy to set up USB  :Smile: ) and bingo, one working master and slave setup.

I'll have a fiddle with the Windows builds of apcupsd in a bit so that all three systems will be running in sync  :Smile: 

Only downside is the UPS runs at 95% load with all three machines on - should have gotten the 1000VA - ah well you live and learn  :Wink: 

----------

## whiskeypriest

Thanks.

I'd be interested in hearing about your experiences with apcupsd under Windows; this is one area I haven't explored extensively, but would eventually like to add to the main document (for those running heterogeneous environments).

----------

## ectospasm

When I get the time (which I probably won't have for more than a month) I'll play around with the Windows port of apcupsd.  I'm running APC PowerChute Personal addition,  and that suffices for now.

Any tips aaronjb on getting apcupsd working under Windows?  I really don't like the fact that PowerChute doesn't keep a log of what goes on, so I can't be sure how long powerfail tests take.  And I'm not gonna shell out for the professional addition...

----------

## mark_lagace

 *Quote:*   

> NOTES ON MISCELLANEOUS FUNCTIONALITY:
> 
>     * Currently, apcupsd on USB UPS units does not send the UPS into hibernation when it powers down the system(s) it supports. This means that while apcupsd will monitor the status of the UPS and shutdown its supported system(s) as appropriate, it will not automatically bring the UPS and its supported systems(s) back online when power returns, as the UPS itself is never shut down (unless, of course, youre without power long enough that the UPS actually exhausts itself). Please see this section of the Troubleshooting apcupsd with USB thread for more details, but this functionality should be enabled sometime in the near future. Once apcupsd includes this feature for USB UPS units, Ill update this document with general guidelines regarding the procedure for making sure your system(s) come back to life automatically following a UPS-induced shutdown. 

 

Assuming your UPS supports it, you can have acpupsd kill the power to your UPS.  The problem lies in the default 'onbattery' script and the system 'halt' script.  Here's what I did:

First things first:  The Problem...

  If you want your computer to automatically restart after a powerfail situation (as is the case for most servers) then you need to have a couple things set up to happen: The system has to be set up to boot up when it gets power.  This is usually just a simple BIOS setting. The system has to lose power!  When there is a UPS attached this doesn't happen unless the UPS is told to shut off power, or it completely drains the battery (and thus has no power to provide).  With proper shutdown scripts though, your system will shutdown before the UPS is completely drained, at which point there's no load on the UPS and the battery can last a very very long time.  Since the computer never detects that the power was cut out, it conversely never detects that the power is back on and that it should boot up.

apcupsd is capable of sending the "--killpower" command to the UPS, but in the default setup that happened when I emerged apcupsd-3.10.15-r1 this didn't happen.  After much poking around, here's what worked for me.  For the record, my UPS is the APC BackUPS XS800 (model BR800 according to the USB info).

The solution.

apcupsd apparently checks for the presence of the file /etc/apcupsd/powerfail when the command to kill the ups power is sent to it.  If this file does not exist, it ignores the request.  If use the command /etc/apcupsd/apccontrol killpower, you'll see the following output:

```
Apccontrol doing: /usr/sbin/apcupsd --killpower on UPS

apcupsd FATAL ERROR in apcdevice.c at line 127

Cannot find /etc/apcupsd/powerfail file.

 Killpower requested in non-power fail condition or bug.

 Killpower request ignored at apcdevice.c:127

```

N.B. DO NOT DO THIS:  To test out if I could get apcupsd to shut off my UPS, I manually created the /etc/apcupsd/powerfail file and re-tried the apccontrol killpower command.  Lo and behold, it worked (and my system went ker-clunk as power was cruelly and heartlessly yanked from it).

Thus, all that was left was to automate the process and get it happening at the right time...

To do this, you'll need to modify 3 files.  First, edit /etc/apcupsd/powerout (in my case, it's symlinked to /etc/apcupsd/onbattery).  Add the following line prior to the exit 0 line:

```
touch /etc/apcupsd/powerfail
```

This will create the file /etc/apcupsd/powerfail when apcupsd detects loss of power.

Now edit the file /etc/apcupsd/mainsback and add the following command before the exit 0 line:

```
rm -rf /etc/apcupsd/powerfail

```

This will get rid of that file if the power comes back.  N.B. The default init script for apcupsd automatically deletes the /etc/apcupsd/powerfail file upon apcupsd startup, so you don't have to worry about modifying any startup scripts to get rid of it.

The last thing to do, is to get your shutdown scripts to call /etc/apcupsd/apccontrol killpower when they are done shutting everything down.  Edit the file /etc/init.d/halt.sh and add the following commands at the end of it:

```
# Attempting to add APCUPSD's killpower function here

if [ -f /etc/apcupsd/powerfail ]; then

        ewarn "Powerfail situation - shutting off the UPS"

        /etc/apcupsd/apccontrol killpower

        sleep 120

        exit 1

fi

```

The "sleep 120" line is required to give apcupsd enough time to send the commands to the UPS.  You may need to increase this value if it's too low for your system.

DISCLAIMER:  This worked for me.  I can't guarantee it will work in every situation, but the general concept is sound.  The basic idea is to have your system issue the command "/etc/apcupsd/apccontrol killpower" when it shuts down, if there has been a power failure.

If there are other things that should be modified, or better places to stick the modifications, I'd appreciate any insight you might have.

----------

## whiskeypriest

That's a nice piece of work, sir.

I've tested this three times on the following configuration:P4 2.53GHz, SiS chipset, gentoo-dev-sources-2.6.8-r10, Back-UPS XS 800, standalone configuration....and it seems to work.  The only issue I had was during the first test: I apparently forgot to restart some service or another after making the changes you advised, and was rewarded with an immediate shutdown of my system (followed shortly thereafter by the UPS unit shutting down, as advertised).  After bringing the system back online, subsequent tests ran without incident i.e. UPS support until shutdown parameters reached, followed by a graceful system shutdown, followed by the UPS unit itself powering off.

I didn't expect this functionality until apcupsd-3.10.16, so while we're all waiting for that, your solution seems to be an excellent workaround.  Rather than rewriting a perfectly good post, I've simply linked to it from the main document.

Please remember, all: take the proper precautions before giving this a go, e.g. back up the files you're changing, make sure your system is prepared for a sudden/possibly-catastrophic loss of power, etc.  Just because two people were able to make this work doesn't make it gospel.

With all that said...thanks for posting, Mark!  If anyone has any issues with this or needs help implementing it, feel free to post to the Troubleshooting apcupsd with USB thread.

----------

## mad_turk

Mr. whiskey & others,

Which version of PowerChute have you guys installed on your gentoo machines?

Thanks,

----------

## ectospasm

 *mad_turk wrote:*   

> Mr. whiskey & others,
> 
> Which version of PowerChute have you guys installed on your gentoo machines?
> 
> Thanks,

 

Unless you've got access to the Business Edition, PowerChute is Windows or MacOS only.  Besides, apcupsd is a free replacement of PowerChute.  I can't wait for apcupsd to support USB cables in Windows;  then I can ditch PowerChute altogether...

----------

## ectospasm

My hard drive crashed, and so I have to go through the apcupsd setup again.  Again, great job on this HOWTO whiskeypriest.

I have some suggestions, though:

You might want to mention that with the current version of apcupsd (3.10.16), the /etc/apcupsd/apcupsd.conf file has a heavy dose of comments, so it's quite easy to figure out what each option does, and tailor it for your needs.  RTFM (or RTFConfigFile) would apply here.

In the Communications Test, where you disconnect the USB cable, you might want to mention that the message in /var/log/apcupsd.events may not appear immediately.  It didn't for me just now.  However, it did recognize the reconnect immediately.  I think you should say that YMMV.

Another thing you can mention is that you can comment out the Wall=wall variable in /etc/apcupsd/apccontrol to get rid of those annoying console messages.  Just make sure to note that (according the apcupsd docs) it will be replaced when you upgrade apcupsd.  I couldn't figure a better place to do it.

I'm about to do the full powerfail test.  I'll come back and edit this if there are any other suggestions I can make.

[edit]Added the "comment out Wall=wall" suggestion

----------

## whiskeypriest

ectospasm:

First off, thanks for the input.  Let me take this point-by-point...

 *ectospasm wrote:*   

> You might want to mention that with the current version of apcupsd (3.10.16), the /etc/apcupsd/apcupsd.conf file has a heavy dose of comments, so it's quite easy to figure out what each option does, and tailor it for your needs. RTFM (or RTFConfigFile) would apply here.

 

I'm glad to hear it; I haven't seen 3.10.16 yet, because I don't have the appropriate keywords enabled for apcupsd.  While part of me would very much like to see what's coming, I don't feel it's appropriate to maintain one version of this HOWTO for the stable release and another for the currently-masked version.  I think the HOWTO is verging on unwieldy as-is and such additions would probably add more confusion to what was supposed to be a straightforward procedure.  Corollary to this is the fact that my time is very limited these days, and there just aren't enough hours in my day to maintain parallel documents.

All that said, I'm glad to hear they've added more comments to the configuration file; I'm sure many (myself included) will find those comments useful.  I make numerous exhortations to check out the apcupsd User's Manual within the course of the HOWTO, and I expect serious users to pay attention to their configuration files...but this is still a HOWTO, written to assist people in achieving functionality with a minimum of fuss and hair-pulling.  I don't believe RTFM (or RTFConfigFile) has a place in most HOWTO's, despite the fact that it's very good advice.

 *ectospasm wrote:*   

> In the Communications Test, where you disconnect the USB cable, you might want to mention that the message in /var/log/apcupsd.events may not appear immediately. It didn't for me just now. However, it did recognize the reconnect immediately. I think you should say that YMMV.

 

Never experienced this personally, but my experience isn't universal.  Done.

 *ectospasm wrote:*   

> Another thing you can mention is that you can comment out the Wall=wall variable in /etc/apcupsd/apccontrol to get rid of those annoying console messages. Just make sure to note that (according the apcupsd docs) it will be replaced when you upgrade apcupsd. I couldn't figure a better place to do it.

 

Done.

I realize there are those who might construe my comments here as snotty or defensive; that's certainly not my intention.  I appreciate any feedback on the HOWTO and will incorporate it into the document as I feel appropriate.  My only purpose in the above lines is to clarify my position with regards to the HOWTO's purpose and direction within my present capabilities.

Once again, thanks for the input and I'm glad to hear your system's running once again.

----------

## tnt

 *mark_lagace wrote:*   

> # Attempting to add APCUPSD's killpower function here
> 
> if [ -f /etc/apcupsd/powerfail ]; then
> 
>         ewarn "Powerfail situation - shutting off the UPS"
> ...

 

Well, I've done those modifications and I've menaged to bring down system and power off UPS after that (so, my computer lost power and turned off, too).

But, after few minutes I've put power cord back to the UPS and nothing happened. UPS stayed powered off. I've waited for 15 minutes (to charge a battery a little bit, although it was almost full), and nothing happened again. When I switched on UPS manually, my computer turned on emediately, as was intendend.

Is there any way to explain my UPS it should be switching itself on when power comes back?

P.S. I'm using APC Back-UPS CS 500

----------

## whiskeypriest

Sorry for the delay in replying to this; been on the road the past week.

I've done some digging around the apcupsd-users list, and found this.  Scroll down to the bottom for the official word, but I infer that the CS-series currently has issues "hibernating" properly.  This will hopefully be resolved in 3.10.17, but since 3.10.16 has yet to become stable in Portage, I couldn't tell you when that'll happen...

If you have any luck sorting this, please feel free to post; should you have any other questions, please post them to the Troubleshooting apcupsd with USB thread.

----------

## tnt

Well, 3.10.17 release is out:

http://sourceforge.net/projects/apcupsd

I just hope it will be in portage soon (at least as ~amd64) and I'll give it a try...

----------

## ectospasm

 *tnt wrote:*   

> Well, 3.10.17 release is out:
> 
> http://sourceforge.net/projects/apcupsd
> 
> I just hope it will be in portage soon (at least as ~amd64) and I'll give it a try...

 

I second that vote.  There are supposed to be a lot of fixes in this version.  BTW, anyone know how long it usually takes for a new version of apcupsd to be released in portage?  Who is the Gentoo apcupsd maintainer, anyway?

----------

## tnt

Should we fill a bug request for porting of new version?

----------

## tnt

3.10.17 is in the portage now!

I've emerged it by:

```
ACCEPT_KEYWORDS="~amd64" emerge apcupsd
```

And it WORKS!!!

I mean, it powers my APC Back-UPS CS 500 off (just as 3.10.15 did) but my server turns ON as soon as power is restored to the UPS!

So, it fully functional!

I just hope there's no some stupid bugs, as it's still marked by ~amd64 keyword - I hope it will become "stable" soon so I can sleep without nightmares...  :Smile: 

----------

## tnt

Unfortunately, there's one thing that I don't remember I had with 3.10.15...

From time to time, there are some strange "time left" readings from apcupsd:

```
titan etc # apcaccess status

DATE     : Sat Apr 02 16:57:48 CEST 2005

HOSTNAME : titan

RELEASE  : 3.10.17

VERSION  : 3.10.17 (18 March 2005) gentoo

UPSNAME  : titan

CABLE    : USB Cable

MODEL    : Back-UPS CS 500

UPSMODE  : Stand Alone

STARTTIME: Sat Apr 02 05:01:44 CEST 2005

STATUS   : ONLINE

LINEV    : 000.0 Volts

LOADPCT  :  21.0 Percent Load Capacity

BCHARGE  : 100.0 Percent

TIMELEFT : 1582.0 Minutes

MBATTCHG : 15 Percent

MINTIMEL : 5 Minutes

MAXTIME  : 0 Seconds

OUTPUTV  : 230.0 Volts

DWAKE    : 000 Seconds

DSHUTD   : 000 Seconds

LOTRANS  : 000.0 Volts

HITRANS  : 256.0 Volts

ITEMP    : 29.2 C Internal

ALARMDEL : Always

BATTV    : 13.5 Volts

LINEFREQ : 49.0 Hz

NUMXFERS : 0

TONBATT  : 0 seconds

CUMONBATT: 0 seconds

XOFFBATT : N/A

SELFTEST : NO

STATFLAG : 0x02000008 Status Flag

SERIALNO : BB0443020465

BATTDATE : 2004-10-21

NOMBATTV :  12.0

FIRMWARE : 08.q5.I USB FW:q5

APCMODEL : Back-UPS CS 500

END APC  : Sat Apr 02 16:57:48 CEST 2005
```

Your expiriance with this?

 :Confused: 

----------

## quantumwire

My motherboard is not an ATX compliant board so in my case "shoutdown -h now" command doesn't turn off my pc.

Is there a way to power off my USB Back UPS CS 650 instead of my pc?

----------

## tnt

Yes: emerge newest 3.10.17 apcupsd and follow these instructions:

https://forums.gentoo.org/viewtopic.php?p=1928915&highlight=#1928915

 :Smile: 

----------

## ectospasm

 *tnt wrote:*   

> ...as it's still marked by ~amd64 keyword - I hope it will become "stable" soon so I can sleep without nightmares... :)

 

I want to say it was Jason Huebel (the Gentoo AMD64 Strategic Lead) who told me this(I may be compeletly wrong, I remember reading it on IRC, #gentoo-amd64@Freenode), but don't expect any packages to be marked amd64 "stable" for a while.  The developers are so busy trying to get packages that are masked to work under x86_64 that they don't have time to mark any of them stable.  Just put ACCEPT_KEYWORDS="~amd64" in /etc/make.conf and be done with it.   I haven't run into any stable/unstable issues since I've done that, AFAIK.

----------

## tnt

Well, that's very very interesting news!

Thank you!

----------

## Master One

 *mark_lagace wrote:*   

> The last thing to do, is to get your shutdown scripts to call /etc/apcupsd/apccontrol killpower when they are done shutting everything down.  Edit the file /etc/init.d/halt.sh and add the following commands at the end of it:
> 
> ```
> # Attempting to add APCUPSD's killpower function here
> 
> ...

 

That function is already implemented in latest (~x86/~amd64) baselayout (I am using baselayout-1.11.11-r3 ATM).

ADDITIONAL NOTE: I had to copy /usr/sbin/apcupsd over to /sbin/apcupsd and change that command variable in /etc/apcupsd/apccontrol, because I have /usr on a separate partition, which gets unmounted before the UPS shutdown is initiated in /etc/init.d/halt.sh! This way UPS hibernation worked out fine, and everything came up again after UPS power restorage. That's a pretty cool setup, I have now with three servers on a SmartUPS 1000  :Smile: 

----------

## Kai Hvatum

Well I drove out to CompUSSR today and purchased an ES 650. I was expecting to spend at least a few hours messing around with various deamons before everything worked but after following your tutorial there are no problems.  

Many thanks whiskeypriest.

----------

## Master One

 *tnt wrote:*   

> Unfortunately, there's one thing that I don't remember I had with 3.10.15...
> 
> From time to time, there are some strange "time left" readings from apcupsd:
> 
> ```
> ...

 

Now that's strange. Didn't see this before, but I now get a similar output:

```
# apcaccess status

DATE     : Tue Jul 12 20:43:05 CEST 2005

HOSTNAME : lanmaster

RELEASE  : 3.10.17

VERSION  : 3.10.17 (18 March 2005) gentoo

UPSNAME  : APC

CABLE    : USB Cable

MODEL    : Smart-UPS 1000

UPSMODE  : Net Master

STARTTIME: Tue Jul 12 20:26:37 CEST 2005

SHARE    : NetworkUPS

STATUS   : ONLINE

LINEV    : 231.8 Volts

LOADPCT  :  65.0 Percent Load Capacity

BCHARGE  : 100.0 Percent

TIMELEFT : 1020.0 Minutes

MBATTCHG : 5 Percent

MINTIMEL : 3 Minutes

MAXTIME  : 0 Seconds

OUTPUTV  : 231.8 Volts

DWAKE    : -01 Seconds

DSHUTD   : 090 Seconds

LOTRANS  : 208.0 Volts

HITRANS  : 253.0 Volts

ITEMP    : 33.3 C Internal

ALARMDEL : Always

BATTV    : 27.4 Volts

LINEFREQ : 50.0 Hz

NUMXFERS : 0

TONBATT  : 0 seconds

CUMONBATT: 0 seconds

XOFFBATT : N/A

SELFTEST : NO

STATFLAG : 0x02000008 Status Flag

SERIALNO : AS0407331798

BATTDATE : 2004-02-14

NOMBATTV :  24.0

FIRMWARE : 00.3.I USB FW:1.5

APCMODEL : Smart-UPS 1000

END APC  : Tue Jul 12 20:43:05 CEST 2005
```

From time to time it reports back the correct battery run time of ~ 17.0 min, but most of the time I get those 1020.0 min.

I have three machines on that UPS, and all of them (the master and the two slaves) report the same wrong battery run time.

Anyone any idea? Looks like a bug was introduces from 3.10.15 to 3.10.17.

----------

## Freppe

 *Master One wrote:*   

> ADDITIONAL NOTE: I had to copy /usr/sbin/apcupsd over to /sbin/apcupsd and change that command variable in /etc/apcupsd/apccontrol, because I have /usr on a separate partition, which gets unmounted before the UPS shutdown is initiated in /etc/init.d/halt.sh! This way UPS hibernation worked out fine, and everything came up again after UPS power restorage.

 

Does anyone know of a way to do this automatically, such as a config option to portage/emerge? I have the same problem as above with a separate /usr partition, but if this is done manually then I need to remember to do it every time I update apcupsd. It would be nicer to have it installed to /sbin directly.

Perhaps the ebuild should be changed to have "sbindir=/sbin" instead of the current "sbindir=/usr/sbin"?

----------

## platojones

Anybody else getting this lately.  I don't know when it started happening, but I just noticed it while doing a ps:

```

root      8585 10943  0 10:43 ?        00:00:00 [apcupsd] <defunct>

root      8587 20641  0 10:43 pts/1    00:00:00 grep apcupsd

```

I haven't done a test to see if it actually still works (though it did a few days ago when I had a real power glitch), but it is annoying.

----------

## segedunum

 *suhlhorn wrote:*   

> 
> 
> 2) The UPS unit does not appear to shut off via the 'killpower' option to apccontrol after the shutdown sequence has completed. Is this a limitation of my UPS (APC Back-Ups RS 1000) or a problem with the shutdown/halt scripts?
> 
> 

 

It's your (and my) halt scripts. The halt script in my baselayout (11.7 I think) look as if they only call upsdrvctl which is a part of NUT I think. Quite why this is supported and not apcupsd I don't know. The halt script that I have does not appear to support apcupsd at all as far as I can see, and there is no call to /etc/apcupsd/apccontrol killpower or check for /etc/apcupsd/powerfail. There is no /etc/apcupsd/powerfail script, so I'm  assuming it gets created dynamically when the power fails (have to check that one). The consequences of this are that when the power returns your machine will not automatically power back on and boot up. I have exactly the same SmartUPS on a Suse server and it works perfectly.

It should be fairly trivial to modify (there's a decent ups_kill_power function) as you can just add the apc stuff in, but it should really be there. Does anyone know if this has been added to recent halt.sh scripts in a new baselayout before I go needlessly modifying my script?

----------

## dashnu

 *platojones wrote:*   

> Anybody else getting this lately.  I don't know when it started happening, but I just noticed it while doing a ps:
> 
> ```
> 
> root      8585 10943  0 10:43 ?        00:00:00 [apcupsd] <defunct>
> ...

 

Any fix for this yet? I get this on my Master and 4 slaves.. Pain in the but.. leaves crap proc entries around also.

TIA

----------

## dashnu

*bump* last post.. and..

None of my network slaves report the correct time.... they all say

Wed Dec 31 19:00:00 EST 1969

Anyone see this?

Also I have a APC room monitoring Card can apcupsd interact with it?

I need something to shut down my servers if the AC dies. What do people use for this??

TIA

----------

## ectospasm

When running "emerge sync":

```
*** Deprecated use of action 'sync', use '--sync' instead
```

This HOWTO still uses the old way of calling sync.  Just a minor nitpick.

We may want to move this HOWTO to gentoo-wiki so whiskeypriest doesn't have to be the only maintainer.  I'd be willing to help with that.

EDIT:  I need to learn to look before I post.  I see that this HOWTO is already on the wiki.

----------

## Flebool

I can't emerge apcupsd, neither version 3.10.17 or 3.10.18

the program emerge fine, but doesn't install any /usr/bin/apcupsd executable. there's no trace of it in the emerge log (scrolling the console, the last things it points out are the files it installs)

Obviously, trying to run the init script "/etc/init.d/apcupsd start" it fails miserably, with the error: "stat /usr/sbin/apcupsd: No such file or directory"

the system is an amd64 machine, but installed like a x86.

my USE flag emerging apcupsd is:

USE="apache2 ncurses nls usb -cgi -doc -snmp -threads"

I've tried disabling apache2 or adding all others, but it doesn't emerge any executable.

Any help?

Next step will be installing manually..

----------

## lmegliol

First off, thanks for this thread and the accompanying Wiki entry.  I have managed to get apcupsd up and running just fine.

Regarding shutdown of slave machines and restarting of servers after power returns... 

From the message about about newer versions of apcupsd automatically supporting powering up systems, it is implied that a simple emerge of the latest version is all that is needed to get this working.  I emerged the latest version and my system does not shutdown completely, nor does it power on (or reboot for that matter) when power returns.  Is there something else I'm missing here?  Do I still need to apply the modifications to kill power to the UPS to get this to work?

The other question I have is whether either methods of getting the server to power on after power resumes takes into account whether slave systems have yet had the chance to completely power off before killing power to the UPS.  Does this happen or is this a configurate that should only be used in standalone mode?

Thanks.

Leo

----------

## lmegliol

I may have answered my own questions. 

First problem was due to partition/mount problems described above.  Copied apcupsd to /sbin and wall to /bin to fix.

Now UPS shuts self down.  During test I noticed that the shutdown gives time for slaves to shutdown.

New question: is the amount of time given for slaves to shut down configurable?

Thanks,

Leo

----------

## lmegliol

Any word on whether the amount of time given for slaves to shut down is configurable?

----------

## jschweg

I appear to be missing the usb apc driver, according to the below:

```

Apcupsd driver usb not found.

The available apcupsd drivers are:

dumb

apcsmart

net

Most likely, you need to add --enable-usb to your ./configure options.

apcupsd FATAL ERROR in apcupsd.c at line 269

Apcupsd cannot continue without a valid driver. 

```

I can obviously re-emerge it, but how to I add this to the compile?

----------

## thoughtform

nano -w /etc/portage/package.use

put in sys-power/apcupsd usb

should fix it.

----------

## huuan

post moved to a more appropriate forum. admin please delete this.Last edited by huuan on Fri Mar 23, 2007 7:54 pm; edited 2 times in total

----------

## huuan

this is related

https://bugs.gentoo.org/show_bug.cgi?id=159354

----------

## geforce

Can I connect many UPSes to one machine to monitor them (i only want to monitor) ?

----------

## Hobbes-X

 *geforce wrote:*   

> Can I connect many UPSes to one machine to monitor them (i only want to monitor) ?

 

If you want to have each UPS connected to only the one computer, you can run multiple instances of apcupsd. If each UPS will be connected to an individual computer, check out using apcupsd's net driver and running a master apcupsd with the others as slaves.

----------

## geforce

I have 14 Upses...

Should i use another software like NUT ?

----------

## trolley

I think I have my kernel set up right, and I know the UPS is detected by the system, but I never get any logs in /var/log/messages and the apcupsd daemon doesn't detect the UPS. I see this if I run dmesg:

```

usb 1-2.5: new low speed USB device using ehci_hcd and address 9

usb 1-2.5: configuration #1 chosen from 1 choice

HID device not claimed by input or hiddev

```

Anyone know why?

EDIT:

Yet again I missed enabling a kernel option...Last edited by trolley on Thu Jun 21, 2007 6:41 pm; edited 1 time in total

----------

## -Ben-

hm I get the following error in /var/log/messages

```

Jun 21 20:38:43 server apcupsd[8126]: apcupsd FATAL ERROR in linux-usb.c at line 597 Cannot find UPS device -- For a link to detailed USB trouble shooting information, please see <http://www.apcupsd.com/support.html>.

Jun 21 20:38:44 server apcupsd[8126]: apcupsd error shutdown completed

```

I don't understand why apcupsd doesn't find my ups.. it is in /dev/usb/hiddev0

dmesg shows the following

```

usb 1-2: USB disconnect, address 3

usb 1-2: new low speed USB device using uhci_hcd and address 4

usb 1-2: configuration #1 chosen from 1 choice

hiddev96: USB HID v1.11 Device [OMRON USB UPS] on usb-0000:00:07.2-2

```

----------

## boniek

Both of you - make sure that you have 

```
[*] /dev/hiddev raw HID device support 
```

selected. It's in Device Drivers->USB Support->USB Human Interface Device (full HID) support

----------

## -Ben-

yes i have selected that.. otherweise I wouldn't get any /dev/usb/hiddev0 device....

I made this error before and didn't get this device.. now it is there and apcupsd still doesn't find the ups

----------

## boniek

 *-Ben- wrote:*   

> yes i have selected that.. otherweise I wouldn't get any /dev/usb/hiddev0 device....
> 
> I made this error before and didn't get this device.. now it is there and apcupsd still doesn't find the ups

 

Are you sure your USB cable is OK?

----------

## -Ben-

hmm no..

i have another ups of the same kind connected via an usb cable to my windows xp machine.. I'will use the other cable now to check that  :Smile: 

----------

## trolley

 *boniek wrote:*   

> Both of you - make sure that you have 
> 
> ```
> [*] /dev/hiddev raw HID device support 
> ```
> ...

 

That was my problem...just figured it out last night. Thanks though  :Smile: 

----------

## -Ben-

hm, checked it.. the usb cable is working...

what could be the problem?

my config file is

```
## apcupsd.conf v1.1 ##

UPSCABLE usb

UPSTYPE usb

DEVICE

LOCKFILE /var/lock

UPSCLASS standalone

UPSMODE disable

```

----------

## trolley

Try getting rid of the DEVICE line.

I used the standalone config from http://gentoo-wiki.com/HOWTO_APCUPSD and it worked.

----------

## -Ben-

removing the device line doesn't change anything.. i don't understand this.. i got all the drivers necessary.. 

```

 ls -l /sys/bus/usb/drivers/

total 0

drwxr-xr-x 2 root root 0 Jun 21 21:16 hiddev

drwxr-xr-x 2 root root 0 Jun 21 21:16 hub

drwxr-xr-x 2 root root 0 Jun 21 21:16 usb

drwxr-xr-x 2 root root 0 Jun 21 21:16 usb-storage

drwxr-xr-x 2 root root 0 Jun 21 21:16 usbfs

drwxr-xr-x 2 root root 0 Jun 21 21:16 usbhid

drwxr-xr-x 2 root root 0 Jun 21 21:16 usblp

```

or did I miss something??

----------

## boniek

I have 

```
DEVICE /dev/ttyS0
```

and it works as well  :Smile: 

 *-Ben- wrote:*   

> hiddev96: USB HID v1.11 Device [OMRON USB UPS] on usb-0000:00:07.2-2 

 

Are you sure you have APC UPS? Mine is seen as:

```
hiddev96: USB HID v1.10 Device [American Power Conversion Smart-UPS 1500 FW:601.3.I USB FW:1.5] on usb-0000:00:1d.0-2
```

----------

## -Ben-

never mind, i got it working with NUT now... 

maybe my ups simply wasn't supported.. doesn't matter nut works  :Smile: 

----------

## kowal

 *Flebool wrote:*   

> I can't emerge apcupsd, neither version 3.10.17 or 3.10.18
> 
> the program emerge fine, but doesn't install any /usr/bin/apcupsd executable. there's no trace of it in the emerge log (scrolling the console, the last things it points out are the files it installs)
> 
> Obviously, trying to run the init script "/etc/init.d/apcupsd start" it fails miserably, with the error: "stat /usr/sbin/apcupsd: No such file or directory"
> ...

 

I'm on amd64 and had same issue. This helped:

```
USE="-* usb" emerge -v apcupsd
```

----------

## nightkhaos

Hi, So I followed your guide and everything works fine BUT one thing.

I came to test it using the TIMEOUT 30 and yanking the power cable out the back of the UPS to see if it worked.

it worked fine right up until AFTER it unmounted all my logical volumes and tried to execute something in /usr/sbin.

Now, is there a setting I can edit that'll make the script run /sbin/halt instead of the apcaccess command that tells the UPS to kill power to the machine?

Thanks.

NightKhaos

----------

## Joseph_sys

[quote="mark_lagace"] *Quote:*   

> ...[snip]
> 
> To do this, you'll need to modify 3 files.  First, edit /etc/apcupsd/powerout (in my case, it's symlinked to /etc/apcupsd/onbattery).  Add the following line prior to the exit 0 line:
> 
> ```
> ...

 

Is this still valid configuration ? I'm using "apcupsd-3.12.4"

When I added line to file  /etc/apcupsd/onbattery:

touch /etc/apcupsd/powerfail

the file: powerfail was not created when I pulled the power cord.

----------

## Wraith

A quick word of caution - as ESR states in chapter 4 of his UPS HOWTO, simply pulling the plug on the UPS creates a floating ground, which can damage your computer (and yourself!).  Unlikely it may be, but it can happen, so be careful.

Other than that, this is a great resource for those of us who have APC UPS's.  Good work!

----------

## madyogi

Know this topic is pretty much old but for everyone that stuck with "--killpower" story, nowdays solution (apcupsd-3.14.13) is to do it not by editing /etc/init.d/halt.sh - it's no longer there. The job is to play with symlinks and runlevels. A ready-for use "apcupsd.powerfail" sits in /etc/init.d   :Wink:    ...at least it should!

If the UPS doesn't power off completely, it's because the script wasn't added to shutdown runlevel.

```
cd /etc/runlevels/shutdown

ls -l

lrwxrwxrwx 1 root root 29 10-09 19:20 apcupsd.powerfail -> /etc/init.d/apcupsd.powerfail

lrwxrwxrwx 1 root root 21 2012-06-16  killprocs -> /etc/init.d/killprocs

lrwxrwxrwx 1 root root 20 2012-06-16  mount-ro -> /etc/init.d/mount-ro

lrwxrwxrwx 1 root root 21 2012-06-16  savecache -> /etc/init.d/savecache

```

The apcupsd.powerfail should be listed among killprocs, savecache and mount-ro (the one apcupsd.powerfail needs)

```
ln -s /etc/init.d/apcupsd.powerfail
```

or with rc-config

```
rc-config add apcupsd.powerfail shutdown
```

To test this:

```
ls -l
```

... and flip the fuse switch or pull the plug!

----------

