Jordan Brown writes: > Ceri Davies wrote: > > I'm completely with you. I'm suggesting that svc.startd is the best place > > to put the hook rather than the kernel. > > The problem is that one of the very last things that is done before the > system shuts down completely is that the file systems are fully sync'ed > out and unmounted. For UFS at least, that has to happen before the > power is removed. That final sync happens inside uadmin(2), inside the > kernel.
Yes, I understand that, and acknowledged the issue multiple times in this thread. My solution for this is an intentional hack: tell the people writing these services that they must build in a delay. They must tell the UPS to give the system a grace period before pulling the rip cord. The reason for making it an intentional hack is two-fold. First, the existing mechanisms for shutting down a UPS are both *complicated* and frequently changing; they're not really amenable to translating into Solaris-specific kernel modules. And secondly, I doubt that we're unique here. I suspect that all non-trivial operating systems have this sort of problem. > If we don't need to do the final sync before turning off the power, or > if we can arrange for userspace involvement after the final sync, then I > would hope that we could do all of the sequencing using SMF dependencies > rather than by putting additional hooks into svc.startd. I'm suggesting something else: telling UPS software vendors that they have to provide sufficient grace time after that final notification such that we can unmount and flush buffers. They can (of course) do an /sbin/sync before sending the message to the UPS just to make sure that the delay between final service finishing and actual system unmount/poweroff is minimal. I agree that having a hook in uadmin(2) is the "perfect" solution. But I think it's a bit too perfect to be usable. At least, I have no idea how to make it work for any of the UPS software I've ever used (including APC's stuff and nut). -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
