The verification of the Stable Release Update for resolvconf has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
-- 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: [SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls Status in resolvconf package in Ubuntu: Fix Released Status in resolvconf source package in Xenial: Fix Released Bug description: [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. 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
