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. -- failure to kill UPS power over snmp/pcnet connection https://bugs.launchpad.net/bugs/602978 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
