root@lp1853164-b:~# dpkg -l systemd|grep systemd
ii systemd 237-3ubuntu10.51 amd64 system and service manager
root@lp1853164-b:~# dpkg -l | grep -E 'ifupdown|resolvconf'
ii ifupdown 0.8.17ubuntu1.1 amd64
high level tools to configure network interfaces
ii resolvconf 1.79ubuntu10.18.04.3 all
name server information handler
root@lp1853164-b:~# grep eth0 /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
root@lp1853164-b:~# ip a show dev eth0
222: eth0@if223: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP group default qlen 1000
link/ether 00:16:3e:16:1c:78 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.202.51.62/24 brd 10.202.51.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe16:1c78/64 scope link
valid_lft forever preferred_lft forever
root@lp1853164-b:~# systemctl is-enabled systemd-resolved
disabled
root@lp1853164-b:~# systemctl is-enabled systemd-networkd
disabled
root@lp1853164-b:~# cat /etc/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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
root@lp1853164-b:~#
root@lp1853164-b:~# dpkg -l systemd|grep systemd
ii systemd 237-3ubuntu10.52 amd64 system and service manager
root@lp1853164-b:~# dpkg -l | grep -E 'ifupdown|resolvconf'
ii ifupdown 0.8.17ubuntu1.1 amd64
high level tools to configure network interfaces
ii resolvconf 1.79ubuntu10.18.04.3 all
name server information handler
root@lp1853164-b:~# grep eth0 /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
root@lp1853164-b:~# ip a show dev eth0
224: eth0@if225: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP group default qlen 1000
link/ether 00:16:3e:16:1c:78 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.202.51.62/24 brd 10.202.51.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe16:1c78/64 scope link
valid_lft forever preferred_lft forever
root@lp1853164-b:~# systemctl is-enabled systemd-resolved
disabled
root@lp1853164-b:~# systemctl is-enabled systemd-networkd
disabled
root@lp1853164-b:~# cat /etc/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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 10.202.51.1
search lxd
root@lp1853164-b:~#
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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
--
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
