Alan Maguire writes:
> Renee Danson wrote:
> > Hmm.  I think Alan's looking for a way to workaround a slightly
> > different aspect of 6696321 that's been problematic for nwam: if
> > nwamd is the thing that first launches dhcpagent (and it usually
> > is), then dhcpagent winds up in nwam's contract.  So in order for
> > the nwam service to shut down properly, dhcpagent must exit as
> > well.  But nwamd needs to communicate with dhcpagent "on the way
> > down", as it usually needs to release dhcp leases as part of its
> > normal shutdown.  So, nwamd winds up needing to kill dhcpagent
> > (this is why the nwam service stop method is an explicit pkill
> > of nwamd, rather than the simpler :kill).

Fixing that CR fixes that problem.

> Right. Sorry - I should have expanded on this a bit more.
> I first took a look at what it would take to get dhcpagent
> in a separate contract. The ideal scenario would be a
> service conversion of course, but slightly less work
> in the interim would have been to ctrun /sbin/dhcpagent
> when it is invoked by libdhcpagent. Problem with this is
> that ctrun is in /usr/bin, so not guaranteed to be available
> early in boot

Putting it in a separate contract is the right idea.  "ctrun," though,
isn't the solution.  Using the contract(4) interfaces solves the
problem.

I can probably provide a fix if you need it.  It's been a minor issue
for things other than NWAM, but it's clearly more of a problem now.

(For what it's worth, I'm still confused by the "-9" -- SIGKILL --
used in the current nwamd.  I don't see how that's the right answer.
I would have thought SIGTERM [the default -- -15] would have been
sufficient.  -9 is far too violent for my taste.)

> One thing that occurred to me later - that SIGTERM will
> also hit the daemon itself and the stop script (since these
> are also part of the contract).

The usual solution to that is to block SIGTERM in the function that
broadcasts the SIGTERM from the main daemon.

-- 
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

Reply via email to