[Bug 1853164] Autopkgtest regression report (systemd/237-3ubuntu10.52)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (237-3ubuntu10.52) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

casync/2+61.20180112-1 (s390x)
nftables/0.8.2-1 (amd64)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64, i386, s390x)


Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1853164

Title:
  systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  with systemd-resolved disabled, dhclient doesn't correctly notify
  resolvconf about dns server(s)

  [test case]

  install resolvconf and ifupdown and disable systemd-resolved and
  systemd-networkd, use ifupdown to get a dhcp address where the lease
  includes a dns nameserver, verify resolvconf is using that dhcp-
  provided nameserver

  [regression potential]

  failure to correctly notify systemd-resolved about new dhclient-
  provided nameserver(s)

  [scope]

  this is needed for f and earlier

  in g and later the hook script is moved to the isc-dhcp package, and
  edited to correctly check is-enabled systemd-resolved instead of only
  checking for the existence of the binary

  [original description]

  The functionality exists to allow users to revert to the traditional ifupdown
  package for network configuration. Alongside this, systemd's often-buggy
  resolver can be disabled. However, there's a logic error in the systemd-
  supplied /etc/dhcp/dhclient-enter-hooks.d/resolved that prevents the system
  from populating /etc/resolv.conf properly when systemd-resolved is disabled.
  The issue is here:

      if [ -x /lib/systemd/systemd-resolved ] ; then

  Instead of checking to see if the systemd-resolved service is enabled or
  active, which would be the correct behaviour, this checks for the existence of
  a binary, assuming that if it exists it's supposed to be used.

  I've not tested this in the absence of resolvconf, but if systemd-resolved
  isn't enabled, it's difficult to imagine this code wanting to run. I've tested
  this with resolvconf and ifupdown driving dhclient, and it corrects the
  behaviour that was broken with the introduction of systemd-resolved.

  I'm attaching a patch, and am also including it here for easy access:

  *** resolved.broken     2019-11-19 15:01:28.785588838 +0000
  --- resolved    2019-11-19 15:08:06.519430073 +0000
  ***************
  *** 14,20 ****
    #   (D) = master script downs interface
    #   (-) = master script does nothing with this

  ! if [ -x /lib/systemd/systemd-resolved ] ; then
            # For safety, first undefine the nasty default make_resolv_conf()
            make_resolv_conf() { : ; }
            case "$reason" in
  --- 14,21 ----
    #   (D) = master script downs interface
    #   (-) = master script does nothing with this

  ! systemctl is-active systemd-resolved > /dev/null 2>&1
  ! if [ $? -eq 0 ]; then
            # For safety, first undefine the nasty default make_resolv_conf()
            make_resolv_conf() { : ; }
            case "$reason" in

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164/+subscriptions