On Wed, Oct 14, 2009 at 11:03:55AM -0700, tester wrote: > Thanks for the suggestions. We did ctrun to separate the contracts > out. I wanted to know if there is something more elegant from a parent > SMF service definition that can do this.
There's a C API; see libcontract(3LIB). But there isn't any facility to _automatically_ decide that the child of some fork(2) call must be in a separate process contract than the parent. This is a problem that all service management schemes for Unix or Linux have to deal with: how do you decide what processes are part of the service (and therefore must be watched, and killed on service restart), and which ones are not. The problem comes from the fact that fork(2) is part of the Unix way of life and goes back to long, long before the advent modern service management facilities -- fork(2) is "legacy" to modern service management. Dealing with legacy code is generally hard. Heuristics might help a bit (e.g., "a child that calls a PAM function must not be part of the service") in some cases, but there's no set of foolproof heuristic rules that could be used in all cases. In other words: the service developer is responsible for explicitly deciding which process progeny are part of the service, and which are not. We give you an API and a CLI that can be used to perform that separation; using them is up to you, the service developer. Nico --
