Table of Contents
You have read UPGRADING in the base directory of the distribution, right?
If not, go read it now, then come back to this file if your question wasn’t answered in there.
Go into your configuration path (/usr/local/ups/etc by default) and copy the sample template files over to their real names. The sample template files are installed with make install and can also be found inside the source distribution in the conf directory.
Go read the UPGRADING file again.
Drivers are occasionally removed from the tree if they are no longer receiving maintenance, or sometimes renamed to better reflect their hardware support scope or replaced by a more generic driver. There have been several architectural changes to the driver code in recent times, and drivers which were not converted by someone are eventually dropped.
This is called progress. We do this in order to avoid a situation where someone believes that a driver is being maintained when it is actually rotting slowly in the tree. It also keeps the tree free of old compatibility hacks for code that nobody actually uses anyway.
To get a driver back into current releases, you need to convert it yourself or get someone to do it for you. This is not difficult. The hardest part of any driver is decoding the protocol, and that’s already been done in the old version.
Answer 1
The drivers drop root privileges long before the serial port is opened. You’ll need to change the permissions on that port so that their new user id can access it. Normally this is "nobody", but it may be changed at compile-time by using configure --with-user.
Read the error message. If you have a permissions mismatch, then you’ll see something like this:
Network UPS Tools - APC Smart protocol driver 0.60 (1.1.7) This program is currently running as youruid (UID 1234) /dev/ttyS2 is owned by user root (UID 0), mode 0600 Change the port name, or fix the permissions or ownership of /dev/ttyS2 and try again. Unable to open /dev/ttyS2: Permission denied
Now is a good time to point out that using "nobody" is a bad idea, since it’s a hack for NFS access. You should create a new role account (perhaps called "ups" or "nut"), and use that instead.
Also, scroll down to the "security domains" question to see an even better way of restricting privileged operations. Neither the drivers nor upsd ever need root powers, and that answer tells you how to make it work.
Answer 2
You can also specify a user with "user=" in the global part of ups.conf. Just define it before any of your [sections]:
user = nut
[myups]
driver = mge-shut
port = /dev/ttyS0In this case, "access denied" means the access to upsd, not the device communication port. You’re being denied since the system has no permission to speak to upsd according to the access controls.
There can be various reasons. To fix it, check:
Refer to the upsd(8) and upsd.conf(5) manpages for more information.
Verify your LISTEN directive. It should be one of the valid IP addresses for the computer running upsd (or 0.0.0.0, which is INADDR_ANY), not an address for a client.
The LISTEN directive lets you pick which interface upsd listens on. If you are trying to limit the clients which can connect to upsd, you either need to use tcp-wrappers or kernel firewall rules.
This isn’t a NUT-specific limitation - it applies equally to your web server or mailer daemon.
The Back-UPS type in the genericups driver works but then I don’t get to use all the nifty features in there. Why doesn’t the right driver work?
The problem lies in your choice of cable. APC’s grey cables generally only do "dumb" signalling - very basic yes/no info about the battery and line status. While that is sufficient to detect a low battery condition while on battery, you miss out on all the goodies that you paid for.
Note that the 940-0095B happens to be a grey cable, but it is actually a dual mode cable and can be used in smart mode. If you have this cable, you need to edit your ups.conf to look like this:
[myups]
driver = apcsmart
port = /dev/whatever
cable = 940-0095BAll other grey cables from APC are assumed to be "dumb".
If your grey cable isn’t the 940-0095B, the solution is to dump that cable and find one that supports APC’s "smart" signalling. Typically these come with the UPS and are black. If your smart cable has wandered off, one can be built rather easily with some connectors and cable - there’s no fancy wiring or resistors.
See this URL for a handy diagram: http://www.networkupstools.org/cables/940-0024C.jpg
There is also a text version of that diagram in the docs/cables directory of the NUT source distribution. Either one should allow you to build a good clone of APC’s 940-0024C cable.
There are simpler solutions involving 3 wires that work just fine too, but Powerchute won’t find the loopback DTR-DCD and RTS-CTS and will be annoyed. If you don’t ever plan to use Powerchute, 3 wires (RxD, TxD, GND) are sufficient.
It should also be noted that the genericups driver has no way to detect the UPS, so it will fire up quite happily if it can open the serial port. Merely having it start up is not necessarily an indication of success. You should start it and then check the status with upsc or similar to be sure that it’s reading the hardware properly.
Answer 1
I try to follow the "tool for the job" philosophy. It may mean more programs running, but the flexibility you get is usually worth it.
Yes, the machine with the UPS attached will generally have 3 processes (driver, upsd, upsmon) running, but this design allows a much bigger setup. Imagine a data room with a bunch of machines all drawing power from the same UPS. The rest of them just run upsmon.
Besides, if upsmon were rolled into upsd, upsd would get even bigger than it is now. You’d have one less process, but the RAM consumption would be pretty close to now.
See data-room.txt for more configuration ideas and explanations.
Answer 2
If this really bothers you, roll up your sleeves and use the sockdebug code to write a "upsmon" type program that sits on top of the state sockets. It won’t work over the network, but it means you don’t need upsd. It also means only one host can monitor the UPS.
This is also a good option to consider if you can’t use networked monitoring code for security or safety reasons.
See the TODO file for more on this and other related topics.
Most users will never have any reason to use upssched. It’s complicated, and getting it right for your situation can be tricky. Having it live in a separate program saves resources and lets most people avoid it completely.
It is also coherent with the answer to the previous question.
Answer 1
New versions of the init man page taken from the sysvinit package are saying that usage of SIGPWR is discouraged, since /dev/initctl control channel is the preferred way of communication.
Answer 2
The name of the game is portability. Not everyone’s init handles that kind of signalling gracefully. What’s more, some admins might want to do things differently even if they have that kind of init running.
So, to be compatible, upsmon just invokes a shell command. If you want to use init’s SIGPWR stuff, just put the right "kill" line in a shell script and make upsmon call it. Everyone wins.
There are at least two different protocols being used for hardware with very similar names. The bestups driver tends to support the units built around the newer "PhoenixTec" protocol, and the bestfortress driver supports the older Best hardware.
There is a similar problem with the tripplite_usb driver: it only supports the older, proprietary protocol. Newer standards-compliant Tripp Lite UPS models are supported by usbhid-ups. We name drivers based on the information available at that time, which often is incomplete.
It means your UPS driver hasn’t updated things in a little while. upsd refuses to serve up data that isn’t fresh, so you get the errors about staleness.
If this happens to you, make sure your driver is still running. Also look at the syslog. Sometimes the driver loses the connection to the UPS, and that will also make the data go stale.
Note: some very slow machines have trouble keeping up with the serial ports during periods of extreme load. My old 486 used to flip between "stale" and "OK" while running backups.
If this happens a lot, you might consider cranking up DEADTIME in the upsmon.conf to suppress some of the warnings for shorter intervals. Use caution when adjusting this number, since it directly affects how long you run on battery without knowing what’s going on with the UPS.
Note: some drivers occasionally need more time to update than the default value of MAXAGE (in upsd.conf) allows. As a result, they are temporarily marked stale even though everything is fine. This can happen with MGE Ellipse equipment - see the mge-shut man page. In such cases, you can raise the value of MAXAGE to avoid these warnings; try a value like 25 or 30.
This means that upsd can’t connect to the driver for some reason. Your ups.conf entry might be wrong, or the driver might not be running. Maybe your state path is not configured properly.
Check your syslog. upsd will complain regularly if it can’t connect to a driver, and it should say why it can’t connect.
Note: if you jumped in with both feet and didn’t follow the INSTALL.nut document, you probably started upsd by itself. You have to run upsdrvctl start to start the drivers after configuring ups.conf.
Assuming you don’t have the problem in the next question, then you probably have an ATX motherboard, have APM or ACPI enabled in your kernel (assuming Linux here), and are reaching the halt at the bottom of your shutdown scripts.
Your machine obeys and shuts down, and stays down, since it remembers the last state when the UPS restarts.
One solution is to change your shutdown scripts so you never reach that point. You want the system to die without reaching the part where the kernel tells it to shut down. A possible script might look like this:
# other shutdown stuff here (mount -o remount,ro ...)
if (test -f /etc/killpower)
then
/usr/local/ups/sbin/upsdrvctl shutdownsleep 600 # this should never return
# uh oh, we never got shut down! (power race?)
reboot
fihalt -p
The other solution is to change your BIOS setting to "always power on" instead of "last state", assuming that’s possible.
This depends on how clueful your motherboard manufacturer is, and isn’t a matter of the OS. You have to do one of the following things depending on what’s supported:
If you can’t use one of the first two options, give the board to an enemy. Let them worry about it.
This is about the same situation as the ATX question above, only worse. Earlier Macs apparently supported a hack where you could cat some magic characters at /dev/adb to enable "server mode". This would instruct the system to reboot while unattended.
From Usenet post <6boftzxz51.fsf@ecc-office.sp.cs.cmu.edu>:
# Send packet over the ADB bus to the PowerMac CUDA chip # telling it to reboot automatically when power is restored # after a power failure.
cat /etc/local/autoboot.adb > /dev/adb
autoboot.adb contains these three bytes (in hex): 01 13 01
Later PowerPC Macs with a PMU and the appropriate kernel driver can achieve the same effect with the following command:
echo server_mode=1 > /proc/pmu/options
The following pages have some slightly more kludgy answers which involve the
use of setpci, and are highly model-specific:
Note: this question has been in the FAQ for several years now, and there’s still no clean answer. Let me guess: everyone who runs a server on Mac hardware has a team of trained monkeys, and feeds them by growing bananas in the tropical environment formed by waste heat from the equipment.
The rest of us are still waiting for the answer. Booting into the Mac OS to frob the "file server" panel is not an acceptable solution.
This is relatively simple to fix. If you have console or VNC access, log in as an administrator, go to System Preferences, click on Energy Saver, click on the options tab, check "Restart automatically after a power failure".
Alternatively, you can connect via SSH and run "sudo pmset autorestart 1" to achieve the same effect.
Using a few role accounts and a common group, you can limit access to resources such as the serial port(s) leading to the UPS hardware.
This is just an example. Change the values to suit your systems.
For my development system this yields the following /dev entries:
0 crw------- 1 nutdev tty 4, 64 Sep 3 17:11 /dev/ttyS0 0 crw------- 1 nutdev tty 4, 65 Sep 3 17:11 /dev/ttyS1
Switch to root, then start the drivers:
# /usr/local/ups/sbin/upsdrvctl -u nutdev start
The listing for /var/state/ups then looks like this:
4 drwxrwx--- 2 nutdev nut 4096 Aug 20 18:37 . 4 drwxr-xr-x 4 root root 4096 May 14 21:20 .. 4 srw-rw---- 1 nutdev nut 0 Sep 3 17:10 apcsmart-ups1 4 srw-rw---- 1 nutdev nut 0 Sep 3 17:10 blazer_ser-ups2
You may have to remove old socket or state files first if you are changing to this security scheme from an older version. The drivers will create new files with the right owners and modes.
Note that /var/state/ups is group writable since upsd will place the upsd.pid file here.
You may have to change the groups of upsd.conf and upsd.users to make them readable. These files should not be owned by nutsrv, since someone could compromise the daemon and change the config files. Instead, put nutsrv in a group ("nut" in this example), then make the files owned by root.nut, with mode 0640.
Once the config files are ready, start upsd:
# /usr/local/ups/sbin/upsd -u nutsrv
Check your syslog to be sure everything’s happy, then be sure to update your startup scripts so it uses this procedure on your next boot.
If you like this, you’ll probably also find the chroot process to be useful and interesting. See security.txt for more details.
The point is limiting your losses. If someone should happen to break into upsd in that environment, they should only gain access to that one user account. Direct access to the serial device is not possible, since that is owned by another user.
There is also the possibility of running the drivers and upsd in a chroot jail. See the chroot.txt provided in the source distribution for an example implementation.
Why give would-be vandals any sort of help?
Put it this way - I wrote good chunks of this stuff, and I still run the programs this way locally. You should definitely consider using this technique.
You probably don’t want to do this, since it doesn’t maximize your runtime on battery. Assuming you have a good reason for it (see the next entry), then look at scheduling.txt or the upssched(8) man page for some ideas.
Wait. upsmon doesn’t consider a UPS to be critical until it’s both on battery and low battery at the same time. This is by design. Nearly every UPS supports the notion of detecting the low battery all by itself. When the voltage drops below a certain point, it will let you know about it.
If your system has a really complicated shutdown procedure, you might need to shut down before the UPS raises the low battery flag. For most users, however, the default behavior is adequate.
Ask yourself this: why buy a nice big UPS with the matching battery and corresponding runtime and then shutdown early? If anything, I’d rather have a few more minutes running on battery during which the power might return. Once the power’s back, it’s business as usual with no visible interruption in service.
If you purposely shut down early, you guarantee an interruption in service by bringing down the box.
See upssched.txt for information on how you can shutdown early if this is what you really want to do.
Those programs need to see a host in your hosts.conf before they will attempt communications. This keeps people from feeding it random "host=" settings, which would annoy others with outgoing connection attempts from your system.
If your hosts.conf turns out to be configured correctly with MONITOR entries and all that, check the permissions. Your web server may be running the CGI programs as a user that can’t read the file.
If you run your web server in a chroot jail, make sure the programs can still read hosts.conf. You may have to copy it into the jail for this to work. If you do that, make sure it’s not writable by any of the user accounts which run inside the jail.
Assuming you haven’t changed the TCP port number on the command line or at compile-time, then you may have some sort of firewall blocking the connection.
upsd listens on TCP port 3493 by default. If you do not specify a LISTEN directive in upsd.conf, upsd only listens on the loopback interface. See the upsd.conf man page for details.
Either find the pid of the background process and send it a SIGHUP, or just start it again with -c reload.
If you send the signals yourself instead of using -c, be sure you hit the right process. There are usually two upsmons, and you should only send signals to one of them. To be safe, read the pid file.
There are several driver to support USB models.
Refer to the driver-name (8) manpage for more information.
The basic USB UPS support was done until NUT 2.2 using hidups. To allow a wider support accross platforms for USB/HID compliant devices, usbhid-ups driver uses libusb (which is available for a wide range of operating systems) and libhid (currently, a modified internal version of it).
As of NUT 2.2, usbhid-ups completely replaces the legacy hidups driver, and provides support for various manufacturers. At that time, newhidups was renamed to usbhid-ups.
usbhid-ups is built automatically if possible (libusb development files need to be installed) and installed by the "make install" command.
On Linux, udev rules are provided to set the correct permissions on device file. This allows the NUT driver to communicate with the UPS, through this device file.
However, the driver may still failed to start and support the device, with a message like:
failed to claim USB device: could not claim interface 0: Operation not permitted
Operation not permitted is a message pointing a privilege issue. The most frequent issue is that udev has not actually applied the rule:
In this case, just unplug and plug back the USB cord, then restart nut.
Sorry, can’t help you there. All official releases are source code and are posted on http://www.networkupstools.org/ along with PGP signatures for verification.
This means all packages have been built by a third party. If you have an issue that’s related to packaging, you will need to seek help with whoever built it for you.
It’s not really two complete copies if your OS forks efficiently.
By default, upsmon runs most of the grunt work as an unprivileged user and keeps a stub process around with root powers that can only shut down the system when necessary. This should make it much harder to gain root in the event a hole is ever discovered in upsmon.
If this really bothers you and you like running lots of code as root, start upsmon with -p and it will go back to being one big process. This is not recommended, so don’t blame us if something bad happens in this mode.
Get the latest stable release, and see if it still happens. If it goes away, it means someone else reported it and got it fixed a long time ago.
If that doesn’t work, try the latest development version.
If your problem is STILL there, then contact the mailing lists.
check the release date on the version you have. If it’s more than about 6 months old, there’s probably a newer stable tree version out there.
No. NUT currently support USB communication through several drivers, and also SNMP and XML/HTTP (Eaton and MGE) communications.
Since NUT is very extensible, support for a new communication bus can be added easily.
Any time there is a gap in features, it’s usually because the group of people who own that hardware and the group of people who write code don’t overlap. The fix is to make them overlap - turn an owner into a developer or vice-versa.
If a release goes by and your patch hasn’t been included, it was probably dropped. There can be a lot of patches waiting for inclusion at some points, and occasionally some have to be rejected.
Design issues or severe coding style problems can be the reason for this. I try to point out what the problems are, but there are limits. See developers.txt for some pointers on submitting patches.
Sometimes patches are put on hold due to a feature freeze. If it doesn’t show up once the new version opens up, send it again.
There’s always work to be done outside of the realm of code bashing. Documentation might not always be so clear. A user’s perspective is sometimes needed to appreciate this. Bug reports on a project’s documentation are just as valuable as those for the actual source.
Fielding questions on the mailing lists is also helpful. This lets other people to focus on coding issues while allowing the original poster to get some information at the same time. It’s quite a relief to open that mailbox and find that someone else has already handled it successfully.
Or a variation like…
This happened to me, and some other people too. The combination of our experiences should prove useful to you.
First, you need to realize that the UPS apparently stores data about the battery, load, and runtime. After replacing the battery, it needs to be clued in to the new situation. If the traditional runtime calibration doesn’t work, you have to try something a little more drastic.
You need to completely drain the UPS while it has a good ground. This means you can’t just pull the plug. You also have to disconnect it from the computer so this software won’t shut it down.
The easiest way to do this is to first unplug your computer(s) from it, and plug in a token load like a lamp. Also, move the UPS to a power strip that doesn’t switch the ground line or an outlet that you can switch off at your panel.
Once the UPS is up at 100% charge (this is important), disconnect the power. It must remain connected to the ground, or the results may not be accurate. Ignore the sounds it makes, and go away until it’s done. Don’t do anything to the front panel while this is happening.
After all of this, put things back the way they should be and let it charge up. You should find that it again gives reasonable values and behavior, as it was when it was new.
Thanks to Matthew Dharm for helping us nail down this procedure.
Temperature scales are handled by the template files, so edit your upsstats.html and change it from TEMPC to TEMPF.
You probably asked a question that’s answered in this FAQ or somewhere else in the documentation and nobody wants to quote it for you.
Convincing the other subscribers that you’ve actually read down this far might be useful. You might mention "queequeg" for better results.
This URL may also be helpful:
If you’re not a programmer, you can still help others by making that protocol available. You might host the document somewhere and send the URL to one of the mailing lists.
Answer 1
It’s a kind of Magic.
Answer 2
It’s both that and a frequently anticipated questions file, too.
The idea is to write it up in here so that nobody asks the mailing list when it finally does get released.
You can rig up a little hack to handle this issue in software.
Essentially, you need to test for the POWERDOWNFLAG in your startup scripts while the filesystems are still read-only. If it’s there, you know your last shutdown was caused by a power failure and the UPS battery is probably still quite weak.
In this situation, your best bet is to sleep it off. Pausing in your startup script to let the batteries recharge with the filesystems in a safe state is recommended. This way, if the power goes out again, you won’t face a situation where there’s not enough battery capacity left for upsmon to do its thing.
Exactly how long to wait is a function of your UPS hardware, and will require careful testing.
If this is too evil for you, buy another kind of UPS that will either wait for a minimum amount of charge, a minimum amount of time, or both.
There is a situation where the power may return during the shutdown process. This is known as a race. Here’s how we handle it.
"Smart" UPSes typically handle this by using a command that forces the UPS to power the load off and back on. This way, you are assured that the systems will restart even if the power returns at the worst possible moment.
Contact closure units (ala genericups), on the other hand, have the potential for a race when feeding multiple systems. This is due to the design of most contact closure UPSes. Typically, the "kill power" line only functions when running on battery. As a result, if the line power returns during the shutdown process, there is no way to power down the load.
The workaround is to force your systems to reboot after some interval. This way, they won’t be stuck in the halted state with the UPS running on line power.
Implement this by modifying your shutdown script like this:
if (test -f /etc/killpower)
then
/usr/local/ups/sbin/upsdrvctl shutdownsleep 120
# uh oh, we never got shut down! (power race?)
reboot
fi