Re: Consider letting /etc/rc.d/mountall require mdnsd

[Erik Bertelsen <bertelsen.erik%gmail.com@localhost>]

2010/2/15 Greg Troxel <gdt%ir.bbn.com@localhost>:

>> 6c6
>> < # REQUIRE: mountcritremote named mdnsd ypbind
>> ---


>
> Are you asking
>
>  Can anyone see a problem with what I'm doing?
>
> or
>
>  Is it ok to check this in to netbsd, so that everyone else gets this?

Yes, I want it to be committed into NetBSD unless it causes problems.

>
>
> To the first question: it seems fine as long as there are no cycles.
> I'd do 'rcorder *' with and without and see what changes and if you're
> happy with that.  'man rcorder' explains most of what's going on.
> Looking at src/etc/rc.d, it seems mdnsd depends on SERVERS, but SERVERS
> only depends on mountcritremote, so this should all work.  Adding the
> dependency makes mountall move later by a fair bit, but in theory that's
> ok or there's a missing dependency.

Yes, I did try rcorder /etc/rc.d/* with and without my change and noticed the
intended effect, i.e. mountall is ordered after mdnsd with my change and well
before mdnsd without it.

>
> To the second: (I'm assuming mdnsd is in the base system.)  I wonder if
> we should have a virtual service RESOLVER that depends on named mdnsd
> ypbind.  It seems as reasonable to depend on multicast dns as it does on
> regular dns.  Does mdnsd somehow query other systems, and delay
> responding until it has an answer?  I could see it start and then answer
> a query 100 ms later saying "no translation available".  Do you
> understand why that doesn't happen to you?

Yes, mdns(d) was added to the base system recently.

Being multicast I expect mdnsd to listen for multicast announcements from other
hosts and optionally be able to send a multicast request for a given name to
give the named resource a chance to respond.

This causes a short delay when querying mdnsd immediately after starting it,
but subsequent queries seem to respond quickly.

Whether adding RESOLVER as suggested above is useful or not is one of the
reasons that I raised the question instead of concluding that my patch is the
final solution :-)

- Erik