On Wed, 2008-04-30 at 06:59 -0400, James Carlson wrote: > 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.
True, but the ifconfig command that nwamd execs should also not cause the service to be restarted. It's just a transient command that could fail for any number of reasons, all of which nwamd should be able to handle. Fixing the larger problem you mention in libdhcpagent won't fix this. I think nwamd just uses system(), so it would be easy enough to have it run ifconfig under ctrun. If nwamd were using the libinetcfg or libdhcpagent API directly, then it would have no way of doing that. It would have to depend on the libraries doing the right thing. I agree with what you're saying. > 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.) It's like buying a new car. Once you have one particular model, you start seeing it everywhere on the road. Now that I'm aware of this contract boundary issue, I'm sure I'll find problems like this everywhere. :-} > 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. Good information, thanks. -Seb
