Public bug reported:
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.
** Affects: resolvconf (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
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
+ 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.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1825194
Title:
resolvconf is racy, which leads to broken resolv.conf in parallel
calls
Status in resolvconf package in Ubuntu:
New
Bug 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
