?

Log in

No account? Create an account

Previous Web | Next Web

Update...

I've been slowly working on my "ButteflyD" software (to allow a standard mail client to access web mail accounts, specifically HotMail in the first instance)... it's starting to come together... and I'm starting to get my head wrapped around C++. I've actually restarted writing it, this time using a KDE app called Umbrello to do UML class diagrams. Umbrello has a code generator capability, which will then generate empty classes for me based on the UML... which is kinda neat and saves me having to mess around quite so much.

My new 'server' is all here now, and is sitting in the middle of my computer room in a cardboard box.

With a mind to installing Fedora Core 5 on my nice new 'server', I upgraded the old box to FC5 using yum over the Net... it worked really well (I was having kittens about this actually... I expected it to crash'n'burn bigtime...) but it's shown up (well, pointed out I guess) an annoyance which has now been compounded into a serious problem...

I had a horrid thought the other day regarding the mobo's lack of serial ports and connectivity of my UPS's comms cable...




OK, so, my UPS is a Belkin Universal UPS (1200W, not that that's important here...). It has both RS232 Serial and USB1.1 connectivity options.

I'm using it in conjunction with Network UPS Tools (aka NUT (www.networkupstools.org)).

So, there's a hardware/design problem with this UPS; it won't do a so-called "soft-off". OK, that's not 100% accurate, there is no way (apparently, accoring to the NUT documentation) to soft-off the UPS from software. It will,however, soft-off it'self if the battery becomes depleted.

The NUT belkinunv driver provides a workaround for this problem, but it involves modifying the system shutdown process (specifically, on Fedora, it requires atleast /etc/rc.d/init.d/halt to be modified... I try to limit how much I change the distro-provided files, so my only modification to that is to export whether its a halt or a reboot, and to use /sbin/halt.local (which Fedora provide an
if [ -x /sbin/halt.local ] ; then
    /sbin/halt.local
fi

chunk for anyway).

The workaround is implemented in terms of a -x wait[=nn] option being available in the driver executable. This can be fired as belkinunv -x wait to cause the driver to sit and wait for the UPS to either deplete the battery (when the UPS will correctly soft-off), or for the utility power to be restored (when the driver will exit and the shutdown script should reboot the system).

If the driver is called with a -k option (which is how it's called when it is to shutdown the UPS load on an "unbroken" UPS), the driver turns the power off for 10 minutes. After this, the UPS will turn the load back on and you have to hope the utility power is back or that there's enough battery life left to get NUT loaded again. This will keep going round in circles until the battery is finally depleted, and there is a strong likelyhood that the battery will be depleted when there are live filesystems and no chance of getting them safe.

The workaround is a bit of an ugly hack. Implementing it means that it becomes necessary to keep checking that any updates to the distro don't destroy any bits of necessary scripting. This is what prompted me to think about this in the first place, as updating to FC5 stopped my shutdown script modifications from existing...

Furthermore, the "wait" code is NOT implemented for the newhidups NUT driver (or more specifically, for the belkin_hid newhidups subdriver), which is how NUT communicates with the Belkin Universal when it's hooked up using USB.

So, my new project is two-fold;

  • First, implement a "better" behaviour for the Belkin Universal UPS's RS232 Serial driver, belkinunv, so that it does the "wait" behaviour when given a -k, rather than than just hoping things work.

  • Second, implement the wait behaviour and the revised -k behaviour in the belkin_hid driver.

These both need to be completed before I dare to leave my new box powered up on all the time... as power flickers are quite common around here.

I finished working on the first part of the project this afternoon, when I tested my revised driver. I'm really rather impressed; I've written a device driver modification (having never even touched device driver code before) in a language I only know bits of (because it's like C++, and even that is a langauge that I don't really know...) and it works..!

Strands: