Nicolas Williams wrote: >>> The ADM event manager service need to hang around until after >>> unmounts of the file systems it manages. But unmounts are not >>> controlled by an SMF service. >> That seems to be the key. Why aren't unmounts controlled by an SMF >> service? Why doesn't it work to make them controlled by an SMF service, >> and make that SMF service depend on your event manager service? > > I don't think that's necessarily the answer. What happens then when SMF > stops the service that would do those unmounts in its stop method? The > same problem will crop up!
[ Note that there's a separate issue that the file systems are not unmounted by a service, but we'll ignore that for now. ] Why do you say that? The problem, as I understand it, is that the event manager service must remain running until after the file systems are unmounted. If you stop the service that "owns" the mounts, which causes the file systems to be unmounted, the event manager is not necessarily stopped. (The mounts depend on it, not the other way 'round.) The event manager service can then be stopped, if desired. That seems like exactly the desired result. (Note: the "mount" service would have to unmounting *all* relevant file systems, not just the ones that are mounted by default. If you regard it as controlling the file system *service* then that's probably OK.) > I think it may be necessary to have a way to tell SMF that a service's > stop method must not time out. Actually, there is a way to do that: > with the timeout_seconds attribute of exec_method. Does svc.startd > honor that attribute of stop methods? The problem is not (as I understand it) that his stop is being timed out. If his stop method succeeds, SMF sees (through the contract) that he lied, and kills his daemon off anyway. If his stop method fails, SMF whines about it. If his stop method doesn't return (and assuming that he's disabled timeout), then it blocks the shutdown.
