Sebastien Roy writes: > On Tue, 2008-04-29 at 16:43 -0700, David Powell wrote: > > b) Take responsibility > > > > If a subcomponent may fail and you don't want its failures to be > > conflated with nwamd's, start it in a separate contract. > > b) seems like a more sensible option. I'll file a bug against nwamd.
As I mentioned in our previous discussion about this, I don't think this is a problem in nwamd or even in the ifconfig that it spawns (that in turn spawns the failing dhcpagent). Instead, it's a problem in libdhcpagent. That's what spawns dhcpagent when necessary, and it should know that *nobody* who is starting that process should really be held responsible for its fate. It could start the process in a new contract. A similar problem exists in ifconfig itself where it invokes in.mpathd. It needs to start a new contract there, because the service that started ifconfig has nothing to do with the background process that we're starting. (Same problem, different daemon.) A longer term (and much better) fix would be to turn dhcpagent and in.mpathd into separate SMF services, and have libdhcpagent and ifconfig simply enabling the service when necessary. What I think is needed for these services (and what holds them back now) is the concept of an "on demand" service. Currently, dhcpagent and in.mpathd will run in the background as long as there's work to do. If there's no work to do, they politely exit the system. Since only the actions of other processes can cause these things to have work to do, and since those other processes are all designed to check if the daemon is running and fire it up if not, the current design keeps the amount of clutter on the system to a minimum. (For what it's worth, this run-only-when-needed design was requested during ARC review long, long ago. Nobody wants a raft of idle processes all waiting for something interesting to do.) Unfortunately, I don't know how to set up an SMF service that can run "sometimes." Perhaps this is like "svcadm enable -t", but it's not quite that. The service itself has to be able to go back into "idle" state (a state that SMF doesn't have) on its own dime, and the output from svcs needs to be unconfusing. And the user shouldn't be confused by how a manual svcadm enable or disable works on it. All of those would be problems with a simple mapping into SMF that doesn't add an "enabled but not currently running any process" (idle) state. The lack of transient service support is the main thing that stopped me from considering any of this back when I was messing about with DHCPv6. -- 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
