Author: Ben Martin
An uninterruptible power supply (UPS) will
allow your computer to continue to function for a period of time when mains power is lost. This can help you to smooth over short-term (1-5 minute) loss of power by running from the UPS battery. When the UPS battery is running low, the UPS can signal your computer to shut down cleanly. With a UPS you can avoid lengthly filesystem or RAID checks due to abrupt power loss. Here are some tips on UPSes in general and how to set one up to protect a Linux machine, even if the model you have lacks explicit Linux support.
Nowadays, you can acquire a UPS for your desktop system for $100-$200, depending on its features. Most cheaper UPSes will power a computer for only 4-5 minutes, so they’re best used to smooth over of short-term power losses and brownouts and to allow a computer system to shut down properly in the event of a longer-term power loss. This later point is especially important when you’re running RAID-5, because having the data on individual disks of such a RAID out of sync might lead to data loss if it’s not properly addressed.
The main things to look for when investigating which UPS to get are the initial cost, the cost of replacement batteries and the frequency with which you’ll have to replace them, the ability to manage and monitor the UPS from Linux, and the watts and volt-amps provided.
The batteries in a UPS degrade over time, resulting in a loss in the total power capacity of the UPS. You might have to replace the batteries in the UPS in three to five years. If you only need to run a machine for five minutes and have the choice of a UPS that can run a machine for seven minutes or one that can give you 10, you can get away without replacing the batteries in the larger capacity UPS for a longer time — though the batteries for the larger UPS will likely be more expensive as well.
Working out the volt amps (VA) and watts that you require by hand is not exactly straightforward. You must ensure that the UPS can provide more VA and watts than you intend to draw from it. The easiest way to work out what VA and watts you need is to use this Web form offered by American Power Conversion. One downside to the APC Web form is that you cannot select which graphics card your system will be running. While you might not be planning to protect a machine running a 3-D game with a UPS, you might have a high-end graphics card in your Linux machine, and it would be nice to know that it is covered by your UPS.
You don’t strictly need the ability to manage and monitor the UPS, but it can make things easier. If your UPS has no software support for Linux, you can use handcrafted methods to detect when the mains power has been lost. The following method was suggested to me by Robert Murphy, who had to use a UPS with no software support to protect a server. The solution in its original form was to attach a modem to the mains power and connect it to the Linux machine, then have the Linux machine monitor the data set ready (DSR) line on the modem. When the mains power is lost, the Linux machine will still be running because it is connected to the UPS. The modem, which is not connected to the UPS, will lose its power source. The Linux machine will detect that the modem is no longer powered the next time it polls the DSR line and start to shut down while the UPS battery still has power.
These days however, you should expect Linux support from your UPS. The software should be able to tell you the battery status and current load on the UPS. Such information is handy for setting up the machine to continue to run until there is only two minutes’ worth of power left in the UPS, and for sending out messages that the system will shut down in N minutes unless power is restored.
You can use apcupsd for many APC UPS units, OpenUPSd for Belkin UPS, or Network UPS Tools to interact with many types of UPS. Network UPS Tools (NUT) has many clients, including one for KDE (shown in figure), another standalone client, and a GKrellMplugin. NUT can communicate with a wide range of UPS devices. Using NUT can make it convenient to add another UPS to a network because you can use the same software to interact with and monitor both units over the network. Another plus side of NUT is that your knowledge of UPS software setup and management is not locked in to a particular vendor. On the other hand, you may not be able to get at all the features and information for your particular UPS unit with NUT.
For this article I’ll use NUT, and I’ll be setting up an APC Smart-UPS SC620.
You can install NUT packages for Ubuntu Gutsy, Fedora 8, and openSUSE. The KDE NUT client, knutclient, is packaged only for Ubuntu and some releases of Mandriva. On a Fedora machine you might want to install the packages nut and nut-client.
Installing the UPS hardware involves connecting a single terminal on the UPS battery, plugging the UPS into the mains power, and connecting the UPS to the computer using either an RS-232 serial interface or USB. A conservative approach is to not immediately power the computer from the UPS but perform an off-line power failure simulation first. More on this shortly.
The NUT daemon has a collection of configuration files in either /etc/nut or /etc/ups, depending on how your NUT was packaged. Unfortunately you must make changes to four configuration files in order to use your UPS. All of the files are well commented, so I will only mention the sorts of changes that are needed.
The ups.conf file should contain a section with the driver name and port to use to communicate with your UPS. The main changes you will likely have to make to upsd.conf are to ensure that the ACLs allow you to connect to the NUT daemon, at least allowing connections from localhost. The upsd.users file is where you set up usernames and passwords and assign which actions each user can perform. You will need to have at least one user in upsd.users so that the monitoring daemon can connect. The fourth configuration file is upsmon.conf in which you tell NUT which UPS units to monitor. The upsmon.conf needs to use the monitoring username and password from upsd.users.
# vi /etc/ups/ups.conf ... [ups] driver = apcsmart port = /dev/ttyS0 # vi /etc/ups/upsd.conf ... ACL all 0.0.0.0/0 ACL localhost 127.0.0.1/32 ACL localnet 192.168.7.0/24 ACCEPT localhost ACCEPT localnet REJECT all ... # vi /etc/ups/upsd.users ... [monuser] password = xxx allowfrom = localhost upsmon master ... # vi /etc/ups/upsmon.conf ... MONITOR ups@localhost 1 monuser xxx master ...
You would think that the packages could have supplied configuration files in a state such that the latter three files would not require changes. If the default were to monitor a UPS named ups on localhost, then the passwords, usernames, and ACLs could have been set up to allow localhost to monitor such a UPS. As you are not likely to ever want to manually use the password for the upsmonitor user, the packages could have just chosen a random string for that password and set up both upsd.users and upsmon.conf for you. As it stands there is a fair amount of busywork you must do beyond just selecting the device and port in ups.conf.
You will find mentions of /etc/killpower throughout the NUT documentation. The main reason for this file is so that just before the computer is about to switch itself off it can tell the UPS itself to shutdown. On Fedora the /etc/init.d/halt script is already set up to do the right thing if the /etc/killpower file exists. On other distributions, a quick grep in /etc/init.d or a similar directory for the killpower string may show that the presence of this file is already handled for you. If /etc/killpower is not handled in your shutdown scripts then the UPS will remain on when the computer shuts down. This is not critical but may cause the UPS to slowly continue to use battery power until it runs out.
With the configuration files in place you should be able to start the NUT daemon by executing service ups start. Assuming that the UPS hardware is on and connected to the computer and that you have named your ups simply “ups” as shown above, you can query its settings with upsc ups. Partial output is shown below. Note that I have changed the battery alarm to sound only when the UPS is running out of battery power. The default is for the UPS to sound an audible alert whenever you lose mains power.
# upsc ups battery.alarm.threshold: L ups.load: 049.4 ups.model: Smart-UPS SC620
The reason to not connect the computer to the UPS right from the start is so that you can conduct an off-line test, in which the computer power is still plugged directly into the wall but the computer is monitoring the UPS and is set to shut itself down cleanly when the UPS alerts the computer that it is running out of battery power. The UPS will alert the computer to shut down only when the UPS battery is running low, so you need to ensure that you have something that will draw power from the UPS during the off-line test — perhaps an old CRT monitor or two. With a monitor running from the UPS, the UPS serial or USB cable connected to the computer, and the computer drawing its power not from the UPS you can start the off-line test. Make sure that the UPS daemon is running, and run tail -f /var/log/messages. Switch off the power to the UPS itself. You should see a message that the UPS has lost mains power and is running on battery. Now you can keep monitoring the battery.charge by running upsc ups periodically. You should see that value steadily dropping, compliments of the monitor drawing its power from the UPS battery. At a certain point the UPS will tell the computer that it has reached a low battery threshold. At this stage NUT should kick in and run shutdown -h now.
The /var/log/messages file should contain entries similar to the following during the off-line test:
... upsmon[29384]: UPS ups@localhost on battery ... ... upsmon[29384]: UPS ups@localhost battery is low ... upsmon[29384]: Executing automatic power-fail shutdown ... upsmon[29384]: Auto logout and shutdown proceeding ... shutdown[32512]: shutting down for system halt
The off-line test is invaluable for verifying that the computer and UPS are communicating correctly. It is comforting to know that the computer will properly shutdown at the UPS’s request before connecting the computer power to the UPS. While the computer is still off after the off-line test is a great opportunity to connect the computer power to run off the UPS. Don’t forget to ensure that the NUT daemon is run at boot by issuing the command chkconfig ups on.
A UPS can keep short-term power losses from affecting your computer. By employing a UPS and using these techniques, you can avoid filesystem checks and RAID-5 revalidations after a power-induced shutdown.
Categories:
- Desktop Software
- Desktop Hardware
