@thayne-u They don't care. There is ample reason to implement a fix for this, but they refuse to do what's best for users because they don't want us to run any software that doesn't start with "systemd". This is a very simple bug with a very simple fix, but they refuse to fix their defects.
I've used Ubuntu as my primary OS since Warty Warthog. I've installed and supported it on countless desktop and server systems. Something changed in the culture a few years back -- they stopped listening to their users, around the time that Jono Bacon left. Now the community has no advocate to influence development. Sadly, that shift in attitude is reflected with this bug and the one like it that I filed in 2018. -- 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 Focal: Triaged 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
