Bug 612625 - avahi-dnsconfd starts too late
Summary: avahi-dnsconfd starts too late
Alias: None
Product: Fedora
Classification: Fedora
Component: avahi
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-08 15:58 UTC by Steve Hill
Modified: 2011-04-06 18:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-04-06 18:11:55 UTC
Type: ---

Attachments (Terms of Use)

Description Steve Hill 2010-07-08 15:58:31 UTC
Description of problem:
The avahi-dnsconfd daemon starts right at the end of boot up.  This means that if you're relying on it to set your DNS servers it won't have done so in time to be used by other services (e.g. mounting NFS filesystems will fail, etc.)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set up a machine that has no other way to learn about DNS servers other than Avahi.
2. Set up some other service that requires DNS, such as the NFS client
3. Boot
4. Watch the other services start (and fail) before avahi-dnsconfd has been started.
Expected results:
avahi-dnsconfd should start as early as possible (i.e. just after avahi itself) so that DNS servers are available immediately.

Comment 1 Lennart Poettering 2011-04-02 01:57:26 UTC
mDNS is completely asynchronous, we never know when the DNS data we have is complete. That makes it impossible to synchronize further boot jobs after dnsconfd, since that would mean we'd have to delay boot for a fixed time, after which we give up looking for DNS data. But this is something we really should not do.

I fear avahi-dnsconfd by its very nature is not really suitable to be used in your setup.

Comment 2 Steve Hill 2011-04-04 09:58:21 UTC
This might be a silly question, but what else is avahi-dnsconfd for, if not auto-configuring resolvers in this way?

Avahi provides much of the functionality previously provided by DHCP (i.e. auto-configuration of services), and is a sensible alternative to using DHCP in an environment where you don't need to hand out IP address leases (e.g. in an IPv6 network, where auto-addressing is handled by stateless autoconfiguration).

It would seem sensible to have a item in the boot process that waits for essential services to be discovered (or a timeout to occur) before continuing.  For example, we can pause the boot process until we know about at least one resolver (doesn't matter whether that has been configured manually, via DHCP, mDNS or some other method - we can continue as soon as we know about a DNS server).

Comment 3 Lennart Poettering 2011-04-06 18:11:55 UTC
Well, in general applications which rely on the network to be up when they are started until they are stopped are kinda broken. Only on fixed machines in a non-mobile 80's world things were like that. Nowadays machines are mobile, connect to different networks all the time. Today networks are configured, removed, configured, removed. An app that cannot cope with that is a broken application, it needs to listen to changes of the network configuration and react dynamically to that. It should not assume that everything is reachable all the time. 

Especially machines where Avahi runs on are like this: mobile, zero-confy, dynamic machines.

In a world like this we don't want to delay bootup just because something is not plugged in, hence avahi-dnsconfd is doing the right thing: it configures DNS when the data is available, it doesn't delay boot for that.

So yeah, I think the general approach of delaying boot for this is broken, and especially in the case of Avahi requiring this is a bad idea.

As the author of Avahi I can btw only say that I never saw the benefit of the unicast DNS server config part of the spec. It offers zero benefits over DHCP, and I would recommend everybody to use DHCP for unicast DNS configuration.

So, doing multicast DNS with Avahi is what I wrote it for. Doing unicast with it is supported mostly for completeness sake, not because I really believe it was a good idea...

Note You need to log in before you can comment on or make changes to this bug.