Network Manager starts before the loopback device is ready, leading to dnsmasq not listening on any interface, breaking DNS resolution
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-
Adding "and static-network-up" to the start condition ensures that /etc/network/
Related branches
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 |
Changed in network-manager (Ubuntu Precise): | |
status: | Triaged → In Progress |
description: | updated |
tags: |
added: verification-done removed: verification-needed |
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.