Skip to content

Instantly share code, notes, and snippets.

@briancline
Last active June 2, 2018 19:18
Embed
What would you like to do?
ubuntu-17.10: Fix resolver behavior for dhclient when systemd-resolved is disabled (fall back to resolvconf)

The problem

So systemd-resolved has bugs. Disabling and stopping systemd-resolved to escape these is the logical step, but a dhcp-managed system does gracefully not fall back to resolvconf-managed file even though dhclient still executes the hook for it. As a result, you're then left with a broken resolv.conf that never gets updated by dhclient.

The reason is the systemd-resolved hook in dhclient only checks to see whether it is executable, and not whether it is also enabled. As a result, it still overwrites the default make_resolv_conf shell function with systemd-resolved logic. Since the resolvconf hook is executed before the resolved hook, you either have to rename it to a name that sorts after resolved, or symlink it thusly; but this doesn't fix the bug.

This diff fixes the resolved hook to actually check for the enabled state of the service in addition to checking whether it is executable. Not the best sequence of steps -- better to check the binary's executable state first, then check whether systemd indicates it's enabled, then override resolver update logic if so. However this does get the job done on a systemd-based system.

--- resolved-orig 2018-06-02 13:41:33.798708435 -0500
+++ resolved 2018-06-02 13:41:49.730987250 -0500
@@ -14,7 +14,10 @@
# (D) = master script downs interface
# (-) = master script does nothing with this
-if [ -x /lib/systemd/systemd-resolved ] ; then
+systemctl is-enabled systemd-resolved.service 1>/dev/null 2>&1
+resolved_enabled_rc=$?
+
+if [ "$resolved_enabled_rc" -eq 0 -a -x /lib/systemd/systemd-resolved ] ; then
# For safety, first undefine the nasty default make_resolv_conf()
make_resolv_conf() { : ; }
case "$reason" in
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment