On Thu, Jul 13, 2006 at 02:19:42AM -0700, Bert Miemietz wrote: > What still remains is the question if it cannot be accomplished to > have children of a daemon (or any other process) in separate > contracts without adding contract related code to the daemon (or > arbitrary program). I guess there is a lot of software that used to > start daemons and that now should be integrated into SMF (e.g. > Oracle, SAP, misc. job control software ...).
Many of these aren't init-style wait services, they would have instead been started by rc scripts in the "old world". For such services, SMF uses contracts to track them as a whole instead of waiting for just a single process. In most cases, we actually wouldn't want them to be creating contracts unless they explicitly create and track them -- SMF can't track errors in the contracts services create. Your case is different in that (correct me if I'm wrong) you want to restart your daemon independent of whether its children are still running. > Couldn't this be done > by activating proper templates in svc.startd for the respective > process. One could configure this in the manifest in a similar way as > follows: > > <exec_method > type='method' > name='stop' > exec='/lib/svc/method/dvamd %m' > timeout_seconds='5' > new_ct_on_fork='true' /> > > or > <propval > name='new_ct_on_fork' > type='boolean' > value='true' /> > > This way no code would need to be modified and there would be no need > for additional interfaces. This is trickier than it sounds from both an implementation and an interface perspective. As far as implementation is concerned, recall that active templates are cleared on exec. As soon as you start a process, be it a shell, your daemon, etc., that active template will be cleared. The interface is actually the biggest difficulty. Do I want every child process to fork? Or just child processes at a depth <=N? What do I do with the contracts which are created? If my start method is a shell script, do I really want every subshell, awk, sed, grep to be in its own contract? You have stumbled across the problem of trying to describe the precise process structure of a service, and that can be arbitrarily complicated. If you really need the benefits of contracts, it turns out that it is much simpler to just use them directly. > But when I decide to move a binary from > inittab to smf it is obvious that I need to configure the service in > a proper way which can be through the manifest. The advantages would > be: > - no code change in software (that might even come from other platforms) > - smf compliance > - hierarchie of pid/ctid could still be resolved In general, no application modifications should be necessary to use SMF. Looking back at your original mail, I think this holds true for your application. The whole contracts discussion may have been a trip off into the weeds. It sounds like when you created your service, you used the default service type. If you instead set the 'startd/duration' property to 'child' (see svc.startd(1M)), you will get behavior that more closely mimics what inittab does. Specifically, your daemon will be restarted when it exits, but startd *won't* kill the entire contract. This is how console-login starts ttymon; we don't want nohup(1)ed processes to be killed when you log out. The one difference between a 'child' style service and something you put in inittab is that if you disable your service, everything its contract *will* be killed. (At least that is the case in the current implementation; I don't know if this is the documented behavior.) But since there's no way to disable a running inittab entry (that I know of), this probably isn't a big problem. It might actually be an improvement. Dave
