On Mon, Jun 02, 2008 at 12:38:22PM -0400, James Carlson wrote: > /sbin/uadmin itself is just a simple command line utility that calls > uadmin(2). I'll assume you mean the latter, as /sbin/uadmin itself > isn't special; anybody with the right privilege can call uadmin(2) > without invoking /sbin/uadmin, and many things that shut down the > system don't bother calling /sbin/uadmin. > > The tricky part of uadmin(2) is that it's (obviously) in the kernel > and that it's often run on a system that's mostly dismantled and about > to be turned off. You have to make policy decisions there (about > whether to turn off the UPS), and it's not always clear how best to do > that.
Which is why I think this feature should be a hook in the kernel. Though even so, if /sbin/uadmin can run, then so can user-land code (in /) run to tell inform the UPS, IF it's simple enough. The same arguments you make against this applies to this being a hook in SMF! > Because it's special, the way in which this case is entered is > special: we know that the UPS software will send a formal and polite > "shut down now" command. It won't just start with uadmin. That shut > down is the point where we can set the trigger to say "when you get to > the power-off point, make sure the UPS goes with you." I agree with this: the decision to do this as the last step should not be made at the last moment. > That, in turn, could be done either by having a special SMF service > that runs dead last, and that tells the UPS "cut power in 5 seconds," If it's dead last then the environment that the service will run with will be barely different from the most minimal environment that a hook in /sbin/uadmin could expect. To me a uadmin hook seems cleaner. > or by having a kernel hook for uadmin(2) that allows a special > UPS-supplied driver to detect when power-off is imminent, and send the > UPS signal -- but only if the UPS-initiated shut down path had been > previously started. > > Of course, those kernel bits are going to get vastly more complicated > if they depend on USB or networking to do the communications work. > > I suspect the service method is going to be much easier to code and > maintain, though the 5 second timer seems gross. I think we basically agree, you just don't know it yet ;) Nico --
