--- In email@example.com
, "Mike Westerhof" <mwester@d...>
> A local chain here (Compusa) is selling an APC UPS (shoebox size)
with USB support for $39 USD. It only supports 200W at 115V, and that
only for a few minutes, but it should suffice for an NSLU2 and few
Great. These really seem usable and, what's even better, there seem to
be at least two driver projects that work with APC: NUT and apcupsd.
The latter is also in debian repositories, so that should be eady to
install on an OpenDebianSlug.
Unfortunately, here in Switzerland the APC ES series in not available.
But I could get one in Germany and use a power adapter. The price is,
however, close to 100$ for the cheapest one.
> In any case, the software is the NUT
software - it seems architecturally
well-suited to the slug. It supports both USB and serial UPS devices.
On the NSLU2 the serial devices will require a USB->serial adaptor.
Since those are almost as much $$ as the UPS, I can't see many folks
going that route, but I happen to have a couple of old serial units
lying about, so that's what I'm testing on right now. The software
builds easily; and once I figured out that the USB/serial driver for
the adaptor I'm using requires a patch, it got a lot easier to test!
:-) It's fairly simple to respond to a "low battery" event by
initiating a shutdown, which is all I've tested and got working so
As mentioned above, have also a look at the apcupsd project.
> The big challenges I see are these:
> a) Lack of USB ports. Nothing to be done about that for the normal
user, I'm afraid. A USB port is required to interface to the UPS,
which cuts in half the amount of storage the slug can handle. There
are some who have found USB hubs that work with the slug, but this is
probably the biggest problem I see in making the software useful. If
support for hubs can be added into Unslung 6, that would be great!
Otherwise, if there were some way to characterize those hubs that DO
work with the slug, there would at least be a repeatable solution for
those who wish dual drives AND an interface to a UPS.
Hmm, I'd try a hub. At least with OpenSlug or OpenDebianSlug the
chances should be good that it will work.
> b) Lack of automatic power-on. The traditional way to handle a UPS
low-battery alert is for the equipment to perform an orderly shutdown,
then signal the UPS to turn off. Doing this leaves the equipment in
the "on" state, the UPS in the "off" state, and since the overwhelming
majority of UPSs will restore power to the load side when the line
power is restored, results in the protected equipment automatically
powering up when the power returns. The NSLU2, however, doesn't do
this (unless, of course, hardware modifications are performed -- see
the howto in the wiki). So it will simply wait for someone to notice
that it's not running, and push the little "power" button. This could
be a real bummer for some, or just no big deal for others. I'd
appreciate feedback from folks to guage just how big a problem this
That's true, but I guess I'd go for the power-on hardware mod. It
seems to be quite easy.
> I'd personally like to see the resolution to item "b" handled a
little differently. My situation may be unusual, though. I'd like the
NSLU2 to go "quiet" after only a few minutes on battery, thus
preserving most of my UPS for the rest of the gear it supports - my
router/firewall and my VOIP. While it might be nice to have my NSLU2
ride out a power failure, it would be even nicer to make sure I have
> I'm not sure how to implement a technique such as this, but this is
what I'd like to be able to do:
> - Upon powerfail, notify interested systems on the network in the
normal "NUT" fashion.
> - After some period of time (5 minutes), put the NSLU2 to "sleep"
> + shutdown all daemons except the NUT processes
> + umount all drives (hopefully permitting them to spin-down and
> + sleep until the UPS either shuts off power, or signals return
of line power
> + if line power remains up for some short period (2 minutes),
> I suspect this will be much harder than it sounds, especially the
umount of the drives (I doubt that's even possible). Hopefully they
can be put in a mode where they will be read-only (ensuring data
integrity), and where they will be "quiet" so they can spin down. Of
course it would also be nice if the "spin-down" features were
implemented in the kernel so the drives could be ordered to do so, but
if wishes were horses...
Nice idea, but not very easy. So you would do a killall to all
processes, then make a ramdisk, cp a minisystem into the ram and
chroot into it. Then it might be possible to umount all drives, and
afterwards use scsi-spin to manually spin them down ???
Maybe it's easier to really shutdown...
> Anyway, that's the idea - feedback is gratefully accepted,
especially if what I'm outlining is totally wrong!
Thanks for your suggestions. I guess, I get one of these. (Although,
to be honest, power outages are very rare here; maybe once or twice a
year, and mostly for just a minute or two...)