Comment 2 for bug 1782275

This issue can be addressed with a manual action, but first you have to dig into the scripts to diagnose the problem, and really if resolvconf is installed then it should just work.

Part of this setup involves disabling systemd-resolved, in favor of a "direct" /etc/resolv.conf, to match the network configuration of other systems at my site. We've also found resolvconf to be a good solution to allow flexibility in how the dynamic resolv.conf file is assembled.

There are at least two issues that I can see here:

1. When there is more than one script in /etc/dhcp/dhclient-enter-hooks.d/ that defines the make_resolv_conf() shell function, the last definition is the one that "wins." If the "resolvconf" script is renamed to e.g. "zz-resolvconf", then it works correctly. This may be a case for renaming systemd's "resolved" script to something like "00resolved" (borrowing an idea from /etc/X11/Xsession.d/), since it is always present in an out-of-the-box install.

2. The "resolved" script takes effect if the /lib/systemd/systemd-resolved executable is present, when it should probably also check that systemd-resolved is enabled. Currently, the script runs even if systemd-resolved is not active, effectively turning into a no-op (albeit a no-op that clobbers resolvconf's functionality).

   That would also fix another use case, where systemd-resolved is disabled and resolvconf is absent. In that scenario, the default make_resolv_conf() function from /sbin/dhclient-script should be used.