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:

Code: Select all

# 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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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):

Code: Select all

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:

Code: Select all

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:

Code: Select all

# /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:

Code: Select all

# 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:

Code: Select all

# 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

Code: Select all

# 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:

Code: Select all

# cat /proc/bus/usb/devices

You should see something analogous to the following:

Code: Select all

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.

Code: Select all

# 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.

Code: Select all

# 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:

Code: Select all

# 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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

# 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.

Code: Select all

## 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:

Code: Select all

## 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:

Code: Select all

# /etc/init.d/apcupsd start

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

Code: Select all

  * 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

Code: Select all

# 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:

Code: Select all

# /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:

Code: Select all

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:

Code: Select all

# /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:

Code: Select all

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:

Code: Select all

#
# 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:

Code: Select all

# ps fax

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

Code: Select all

  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:

Code: Select all

# tail /var/log/messages

You should see something similar to the following:

Code: Select all

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:

Code: Select all

# apcaccess status

Your output should resemble the following:

Code: Select all

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:

Code: Select all

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:

Code: Select all

# 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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

# 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:

Code: Select all

# 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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

# 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:

Code: Select all

# /etc/init.d/apcupsd restart

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

Code: Select all

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:

Code: Select all

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:

Code: Select all

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...

Code: Select all

# 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?

Code: Select all

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

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

Code: Select all

## 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:

Code: Select all

# /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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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.

[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:

Code: Select all

* 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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

# 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:

Code: Select all

# /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:

Code: Select all

# USB support 
# 
CONFIG_USB=y

...versus mine:

Code: Select all

# USB support 
# 
CONFIG_USB=m

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

Code: Select all

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...

Code: Select all

<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

Code: Select all

<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:

Code: Select all

#
# 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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

 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!:)), but after a certain amount of time my computer hangs. Would anyone know a fix/workaround for that?

[GTVincent]

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]

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 )

[*]What sort of motherboard are you using?

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

[*]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?

[*]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...).

[*]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.

[*]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.

[*]Is there anything else you’re running/using/etc. which might explain this behavior?[/list]

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

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:

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]

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

[*]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

[*]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.

[*]You have one instance of a power-failure notification in your logs, but the apcupsd log does not corroborate this power failure.[/list]

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.

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.

[*]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

[*]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.

[*]Do you have SMP support enabled in your kernel? If so, do you actually need it?[/list]

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

[ 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

[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:

Code: Select all

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:

Code: Select all

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