Network Manager starts before the loopback device is ready, leading to dnsmasq not listening on any interface, breaking DNS resolution

Bug #993379 reported by Stéphane Graber
74
This bug affects 11 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
High
Mathieu Trudel-Lapierre
Precise
Fix Released
High
Mathieu Trudel-Lapierre
Quantal
Fix Released
High
Mathieu Trudel-Lapierre

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.

Changed in network-manager (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in network-manager (Ubuntu Precise):
importance: Undecided → High
status: New → Triaged
milestone: none → precise-updates
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Seems weird to me, but I'm not against fixing that part of the configuration provided it provably doesn't introduce regressions (delays in booting up, waiting for the network). NM itself should be checking that lo is up and has some code (disabled I think in Ubuntu) that tries to bring lo up. Maybe it's worth checking if we want that to be done by NM... but fixing the upstart condition looks like an easy way to tackle the issue.

Changed in network-manager (Ubuntu Quantal):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Changed in network-manager (Ubuntu Precise):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Changed in network-manager (Ubuntu Quantal):
status: Triaged → In Progress
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

I can reproduce this issue pretty much at will with a precise VM. Having the dhcp server on the same host likely aggravates the issue by giving NM an ip before lo has time to come up.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.9.4.0-0ubuntu5

---------------
network-manager (0.9.4.0-0ubuntu5) quantal; 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)
  * debian/patches/git_remove_ifpppstatsreq_6b64e4d.patch: remove the use of
    the ifpppstatsreq struct, which has been dropped in newer kernels: use
    ifreq and ppp_stats separately instead.
 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 23 May 2012 15:28:36 -0400

Changed in network-manager (Ubuntu Quantal):
status: In Progress → Fix Released
Changed in network-manager (Ubuntu Precise):
status: Triaged → In Progress
description: updated
Revision history for this message
Chris Halse Rogers (raof) wrote : Please test proposed package

Hello Stéphane, or anyone else affected,

Accepted network-manager into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in network-manager (Ubuntu Precise):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Lele (controllore) wrote :

I have enabled proposed package and I have installed everything including network-manager. Now it go well and in startup the dns go well. Before, just turned on the PC, I was forced to go off end then on the network-manager to work. Thank you, for me the bug is fixed.

Revision history for this message
Lele (controllore) wrote :

I forgot ... I had this bug, even if my system is a new installation 12.04LTS

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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 <email address hidden> Thu, 24 May 2012 20:39:12 -0400

Changed in network-manager (Ubuntu Precise):
status: Fix Committed → Fix Released
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/993379

tags: added: iso-testing
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.