[Bug 1825194] Re: [SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls

[Robie Basak]

Hello Alfonso, or anyone else affected,

Accepted resolvconf into xenial-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/resolvconf/1.78ubuntu7 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, details of your
testing will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: resolvconf (Ubuntu Xenial)
       Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-xenial

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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 Committed

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