** Description changed:
- The functionality exists to allow users to revert to the traditional ifupdown
- package for network configuration. Alongside this, systemd's often-buggy
+ [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.
+ from populating /etc/resolv.conf properly when systemd-resolved is disabled.
The issue is here:
- if [ -x /lib/systemd/systemd-resolved ] ; then
+ if [ -x /lib/systemd/systemd-resolved ] ; then
- Instead of checking to see if the systemd-resolved service is enabled or
+ 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
+ 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
+ # (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
+ # 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
+ # (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
+ # For safety, first undefine the nasty default make_resolv_conf()
+ make_resolv_conf() { : ; }
+ case "$reason" in
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1853164
Title:
systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
