failure to kill UPS power over snmp/pcnet connection

[Matt Chan]

Binary package hint: apcupsd

10.04 LTS server
apcupsd version: 3.14.6-3ubuntu1

If a snmp/pcnet connection is being used to connect to an APC UPS, the UPS will fail to power down after the server has shutdown. However, the behaviour should not have an issue if a serial or USB connection is used (unverified). The proper behaviour is for apcupsd to kill power to the UPS outlets and signal it to enter hibernation mode.

The improper behaviour is caused by the /etc/rc0.d/S35networking script being called before the /etc/rc0.d/S90halt script. The apcupsd command to power down the UPS outlets is in /etc/rc0.d/S90halt.

A temporary workaround is to disable the /etc/rc0.d/S35networking script and append "/etc/init.d/networking stop" in the /etc/rc0.d/halt script immediately before the halt process is called.

[David Sugar (dyfet-deactivatedaccount)]

Thank you for pointing out is interesting scenario. Of course if the ups is locally attached, you want it to shutdown (kill the outlets) last. If it is a remote ups, it may still be for the current machine, so you do not want to shutdown networking before you can send the command to halt the ups, but clearly you still would not want to halt the ups until the end...

I wonder if this plays out (or can play out) any better in upstart, if tied through d-bus events. I suspect ups attached locally vs network would have to be a different kind of d-bus event, though, to notify upstart and make such a solution work there (and I do not think the ups daemon does any d-bus notifications now).

Offhand, I think the long-term solution would be to look at adding d-bus event publishing (or some other means to publish state) in apcd to upstart, at least in respect to where Ubuntu development is going. It is also possible to have something published in a file that can be tested as to whether to postpone network shudown (S35networking could check for) which apcupsd could write. However, either kind of solution will require involving the upstream and thought about how it effects init, hence it may lend itself to a quick hack, and I consider it a valid scenario to consider finding a better solution for.

[Matt Chan (talcite-gmail)]

Sorry, I'm not entirely familiar with D-bus architecture, but does it run when X isn't running? Most servers won't bother starting X.

As for the difference in shutdown times between USB/serial and networked UPSes, we can take advantage of the shutdown delay variables on most UPSes. On the UPSes I'm using, there's a variable that determines the delay between receiving the output power shutdown signal and the actual event of shutting down outlet power. Most delays are configured between 90s and 270s, so it is plenty of time for us.

Even if a USB/serial connected UPS is signalled to shutdown before the networking service is stopped, it will still have time to shutdown. In my particular case, networking is shutdown immediately after the outlet shutdown signal is sent, and immediately before halt is called. Our servers have 270s to shutdown networking and call halt, which should be plenty of time for everyone.

Matt