This bug was fixed in the package network-manager - 0.9.4.0-0ubuntu4.1
---------------
network-manager (0.9.4.0-0ubuntu4.1) precise-proposed; urgency=low
* debian/network-manager.upstart: add "and static-network-up" to ensure the
loopback device is really up before we start dnsmasq. (LP: #993379)
* debian/patches/git_kernel_ipv6_default_route_77de91e.patch: avoid fighting
with the kernel for what IPv6 default route should be set: let the kernel
set his own, then add a new route with a different metric so that we can
go back and remove it later. (LP: #988183)
* debian/patches/nm-ip6-rs.patch: avoid disconnections due to RDNSS expiry,
send a Router Sollicit to try and get new RDNSS data. (LP: #993571)
-- Mathieu Trudel-Lapierre <mathieu...@ubuntu.com> Thu, 24 May 2012 20:39:12
-0400
** Changed in: network-manager (Ubuntu Precise)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/993379
Title:
Network Manager starts before the loopback device is ready, leading to
dnsmasq not listening on any interface, breaking DNS resolution
Status in “network-manager” package in Ubuntu:
Fix Released
Status in “network-manager” source package in Precise:
Fix Released
Status in “network-manager” source package in Quantal:
Fix Released
Bug description:
[Impact]
DNS resolution on systems. Systems where boot is fast enough or slow enough
that NetworkManager starts and spawns dnsmasq before the loopback interface is
ready would observe the issue.
[Development Fix]
network-manager 0.9.4.0-0ubuntu5. Simple update to the upstart job.
[Stable Fix]
Same as above, a minimal modification to the upstart job to add 'and
static-network-up'. Tested independently, outside of a package update by
Stéphane Graber.
[Test case]
1) Boot
2) Verify that dnsmasq is started and listening on the loopback interface
(127.0.0.1). Can be easily verified with ps -ef.
[Regression Potential]
Minimal. If the loopback was to fail to be set by ifupdown, NetworkManager
will start and still exercise the issue. If the boot process is sufficiently
crippled by local changes to not emit static-network-up; NetworkManager would
fail to start.
---
It's been reported by users on IRC that network-manager in some cases spawns
a dnsmasq process that doesn't listen on anything.
This only happens at boot time and disappears after reconnecting.
The problem was tracked down to network-manager.conf triggering before
the loopback interface is ready.
Adding "and static-network-up" to the start condition ensures that
/etc/network/interfaces was parsed and all interfaces in there have
been ifup'ed, fixing the race.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/993379/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
