Bug 612625
Summary: | avahi-dnsconfd starts too late | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Steve Hill <steve> |
Component: | avahi | Assignee: | Lennart Poettering <lpoetter> |
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 13 | CC: | lpoetter |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-04-06 18:11:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Steve Hill
2010-07-08 15:58:31 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. 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). 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... |