| 2019-04-17 14:26:31 |
Alfonso Sanchez-Beato |
bug |
|
|
added bug |
| 2019-04-17 14:27:25 |
Alfonso Sanchez-Beato |
description |
It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395):
$ cat /run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
$ cat /run/resolvconf/interface/NetworkManager
nameserver 192.168.1.6
nameserver 192.168.1.2
This can happen easily when calling "netplan generate", which can re-start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like:
$ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd
$ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd
Eventually, this leads to a resolv.conf that is not consistent with the last run command. |
It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395):
$ cat /run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
$ cat /run/resolvconf/interface/NetworkManager
nameserver 192.168.1.6
nameserver 192.168.1.2
This can happen easily when calling "netplan apply", which can re-start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like:
$ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd
$ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd
Eventually, this leads to a resolv.conf that is not consistent with the last run command. |
|
| 2019-04-17 15:45:01 |
Alfonso Sanchez-Beato |
attachment added |
|
debdiff.patch https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+attachment/5256569/+files/debdiff.patch |
|
| 2019-04-17 16:21:58 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2019-04-17 16:22:06 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2019-04-17 18:15:59 |
Ian Johnson |
bug |
|
|
added subscriber Ian Johnson |
| 2019-04-17 22:13:42 |
Brian Murray |
tags |
patch |
disco patch |
|
| 2019-04-17 22:14:33 |
Brian Murray |
tags |
disco patch |
disco patch rls-ee-incoming |
|
| 2019-04-18 05:21:46 |
Steve Langasek |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-04-18 05:21:46 |
Steve Langasek |
bug task added |
|
resolvconf (Ubuntu Xenial) |
|
| 2019-04-18 05:23:28 |
Steve Langasek |
resolvconf (Ubuntu): status |
New |
Fix Committed |
|
| 2019-04-18 06:33:23 |
Launchpad Janitor |
resolvconf (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2019-04-20 21:40:34 |
Simon Quigley |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2019-04-22 07:36:05 |
Alfonso Sanchez-Beato |
description |
It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395):
$ cat /run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
$ cat /run/resolvconf/interface/NetworkManager
nameserver 192.168.1.6
nameserver 192.168.1.2
This can happen easily when calling "netplan apply", which can re-start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like:
$ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd
$ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd
Eventually, this leads to a resolv.conf that is not consistent with the last run command. |
[Impact]
The bug can lead to non-working DNS. This is a critical bug that needs to be fixed in the stable release.
The patch fixes the bug by using a file lock via the flock command.
[Test case]
This script should eventually stop with the current version, thing that should not happen after applying the patch:
while true; do
printf "\n" | sudo resolvconf -a NetworkManager
printf "nameserver 8.8.8.8\n" | sudo resolvconf -a networkd
wait
printf "nameserver 8.8.8.8\n" |
sudo resolvconf -a NetworkManager &
printf "\n" | sudo resolvconf -a networkd
wait
ping -c 1 www.google.com || break
done
[Regression Potential]
The patch is small and what it does is straightforward. It has also been thoroughly tested. However, the effect if something is wrong would be not being able to resolve DNS names, which is disastrous, so it needs to be very well tested for the SRU.
[Other Info]
It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395):
$ cat /run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
$ cat /run/resolvconf/interface/NetworkManager
nameserver 192.168.1.6
nameserver 192.168.1.2
This can happen easily when calling "netplan apply", which can re-start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like:
$ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd
$ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd
Eventually, this leads to a resolv.conf that is not consistent with the last run command. |
|
| 2019-04-22 07:36:52 |
Alfonso Sanchez-Beato |
attachment added |
|
xenial-debdiff.patch https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+attachment/5257832/+files/xenial-debdiff.patch |
|
| 2019-04-22 07:37:58 |
Alfonso Sanchez-Beato |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2019-04-22 07:41:12 |
Alfonso Sanchez-Beato |
summary |
resolvconf is racy, which leads to broken resolv.conf in parallel calls |
[SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls |
|
| 2019-04-22 12:53:10 |
Simon Quigley |
resolvconf (Ubuntu): importance |
Undecided |
Critical |
|
| 2019-04-22 12:53:11 |
Simon Quigley |
resolvconf (Ubuntu Xenial): importance |
Undecided |
Critical |
|
| 2019-04-22 22:50:03 |
Steve Langasek |
resolvconf (Ubuntu Xenial): status |
New |
In Progress |
|
| 2019-04-22 22:50:14 |
Steve Langasek |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2019-05-01 14:00:28 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2019-05-06 08:46:22 |
Alfonso Sanchez-Beato |
attachment added |
|
xenial-debdiff.patch https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+attachment/5261798/+files/xenial-debdiff.patch |
|
| 2019-05-06 08:47:39 |
Alfonso Sanchez-Beato |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2019-05-11 18:02:41 |
Simon Quigley |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2019-05-15 08:25:55 |
Alfonso Sanchez-Beato |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2019-05-15 12:21:37 |
Robie Basak |
resolvconf (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2019-05-15 12:21:39 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-05-15 12:21:40 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2019-05-15 12:21:43 |
Robie Basak |
tags |
disco patch rls-ee-incoming |
disco patch rls-ee-incoming verification-needed verification-needed-xenial |
|
| 2019-05-15 12:22:03 |
Robie Basak |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2019-05-16 15:23:35 |
Alfonso Sanchez-Beato |
tags |
disco patch rls-ee-incoming verification-needed verification-needed-xenial |
disco patch rls-ee-incoming verification-done-xenial verification-needed |
|
| 2019-05-23 09:25:57 |
Launchpad Janitor |
resolvconf (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2019-05-23 09:26:00 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
