Sebastien Roy wrote:
> Peter Memishian wrote:
>> > I believe, however, that what Dan's describing is a scenario
>> whereby the > daemon is being started and some process attempts to
>> use the door in the > window between door_create() and
>> daemonization. Maybe this isn't during > boot and someone typed
>> "ifconfig plumb bge0" while the daemon was being > restarted, and the
>> daemon is in the process of servicing an upcall while > daemonizing.
>> Will this cause a problem? Do we care?
>>
>> I'm unclear why the daemon was being restarted. Did it crash? If so,
>> I'd
>> say that's an edge condition of an edge condition, and that it
>> wouldn't be
>> a big deal if the ifconfig command failed because its door_call() thread
>> got cancelled. (This whole scenario seems a bit contrived.)
>
> Maybe it crashed, or maybe someone typed svcadm restart linkmgmnt. It
> is a bit contrived, indeed.
>
The case of someone using svcadm to restart linkmgmtd is possible until
we have the ability to make the enabled property of linkmgmtd be
private. Liane mentioned that work is planned for SMF, I can dig up the
e-mail if you're interested, I believe it was a reply from her to one of
my messages on smf-discuss.
>> > > As I recall, the door file is actually packaged (rather than
>> being created
>> > > on demand) so that we avoid having to create it early at boot
>> when the
>> > > filesystem is read-only.
>> > > Yes, but the event Dan's concerned about isn't the door file
>> creation, > but the creation of the server procedure within the
>> daemon (door_create()).
>>
>> I thought one of Dan's earlier suggestions for dealing with this was to
>> have the daemon explicitly create the door file.
>
> I think so, but I'm a bit unclear on how this would solve the problem,
> if we indeed have a problem to solve.
>
Here's a scenario:
A customer is running Solaris with the Vanity Naming changes on a
machine with lots of links.
Currently, network/physical starts after linkmgmtd. linkmgmtd's start
script terminates as soon as linkmgmtd has daemonized. linkmgmtd does
the following after daemonization:
- the avls used to store link data
- open the SMF connection
- populate the avls with data read from SMF
- linkmgmtd initializes the door (calls door_create)
Here's the scenario:
- system boots
- SMF starts linkmgmtd, linkmgmtd daemonizes and the parent returns
- SMF sees linkmgmtd started successfully, and starts network/physical
- linkmgmtd is initializing
- before linkmgmtd is able to call door_create (because there's a lot of
links on this system, reading the link data in from smf takes some
time), the network/physical script tries to plumb the links. It can't
because the door upcall from dls fails
We might not need a large number of links (what's a "large number of
links"? I don't know). We could, theoretically, see this with only one
link. We haven't seen a problem yet because we've gotten lucky. I
think that in most cases we will continue to be lucky and we won't see
the problem. It's those cases where we are not lucky that I'm worries
about.
Dan
