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

> Changing /etc/rc.d/mountall as follows:
>
> diff /etc/rc.d/mountall .
> 6c6
> < # REQUIRE: mountcritremote named mdnsd ypbind
> ---
>> # REQUIRE: mountcritremote named ypbind
>
>
> i.e. by adding mdnsd to the REQUIRE line causes mdnsd to start before
> mountall is called and now the mount succeeds.
>
> I'm not really an expert on the inner workings and dependencies of the
> rc.d scripts, so I just want to solicit comments to the above change,
> which at least in my case seems to work according to my intention (and
> hopefully not harm anyone not using mdnsd).
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?
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.
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?