On Thu, Sep 11, 2008 at 09:45:00AM -0500, Joe Blount wrote: > Bob Netherton wrote: > >Why not make the stop method a little more intelligent so that it > >doesn't block forever ? Maybe the event daemon (or whatever > >the troublesome process) needs to run in a separate contract to > >decouple it a bit from SMF, but a little more massaging of the > >stop method might be the ticket. > > > Thanks Bob! > > I got a reply last night suggesting something similar. > > As I understand it, what I need to do is copy some code from ctrun, to > make make a middle-man daemon that creates and executes a separate > contract (where the real daemon runs).
If you want the daemon restarted then you might as well just execute it via ctrun (but you may want to use two ctrun invocations so that the restarter is itself in a separate process contract from the service). Why copy the code when you can use ctrun directly? If you don't need a restarter, then do copy the contracts_*() functions from $SRC/cmd/ssh/sshd/sshd.c. > Most of the time, the middle man daemon will pass signals on to the real > daemon, and wait for the real daemon to die. (if the real daemon dies, > the middle man will exit, so SMF will restart things) I suppose that works too. > In the special shutdown case where the real daemon should not die, the > middle man will send the "shutdown when your filesystems are gone" > signal then exit. How can the stop method know if it's been called as part of a system shutdown or an svcadm disable invocation? > That would make SMF happy (the daemon it knows about is gone), and the > real daemon would be permitted to hang around as long as it needs to. What happens if the daemon crashes and has to get restarted? Surely it will miss events, and this will be as bad as being stopped while some watched filesystems are still mounted, right? Is there a deeper robustness issue here? Nico --
