/sbin/resolvconf shouldn't abort when /etc/resolv.conf is not a symlink

[Thomas Hood]

In resolvconf up to at least 1.65ubuntu4 the /sbin/resolvconf program exits with status 0 if /etc/resolv.conf is not a symbolic link. This behavior differs in Ubuntu compared with Debian.

    +[ -L /etc/resolv.conf ] || { report_err "/etc/resolv.conf isn't a symlink, not doing anything."; exit 0; }

In the old days resolvconf exited at this point with status 1 which triggered NetworkManager to write /etc/resolv.conf directly. This was not a great idea then (I wrote about this in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/324233/comments/30) but at least it was a reason for exiting at this point.

Now there is no reason for /sbin/resolvconf to exit at this point. Exiting here serves no purpose except perhaps to save a trivial number of cpu cycles. It just prevents resolvconf from updating its database and running update scripts. Even if the admin wants /etc/resolv.conf to be a static file, there still may be some point in running update scripts. Imagine a case is where dnsmasq is running, listening on an external interface serving some special purpose, forwarding queries to another interface, while /etc/resolv.conf points statically somewhere else.

There is no reason to prevent resolvconf from keeping its database up to date. Consider also the case where the admin decides later to restore the symlink to point to /run/resolvconf/resolv.conf.

If there is a reason to prevent some specific update script from running in the case where /etc/resolv.conf is not a symlink, then *that* update script should exit early under those circumstances. /etc/resolvconf/update.d/libc, for example, already exits without running the update-libc.d/ scripts if /etc/resolv.conf is not a symlink to /run/resolvconf/resolv.conf.

[Steve Langasek (vorlon)]

Makes sense to me. I don't think this warrants fixing in precise via SRU, but at least for quantal and forward we ought to drop the delta if it's no longer needed.

[Thomas Hood (jdthood)]

> /etc/resolvconf/update.d/libc, for example, already exits...

I forgot to say "as of version 1.66", so this should be done when 1.66 or later is merged.

The merger will reduce the diff in a couple of other ways and, more importantly, bring in an improved manpage. :)

[Thomas Hood (jdthood)]

Minor note: Making this change will also address the issue mentioned in bug #1003595 (e.g., comment #3): resolvconf reports as an error a configuration which is not necessarily a problem.

[Thomas Hood (jdthood)]

Recently submitted Debian bug report #678316 is relevant here. The submitter wants resolvconf to configure his proxy DNS server but he wants a static file at /etc/resolv.conf.

[Stéphane Graber (stgraber)]

I'm going to have to keep that delta for this merge as network-manager uses the exit code of resolvconf to know whether or not to update /etc/resolv.conf.

I'm opening a task for network-manager to update its logic and instead only call resolvconf if /etc/resolv.conf is a symlink to /etc/resolvconf/run/resolv.conf (Debian) or /run/resolvconf/resolv.conf (Ubuntu).

[Thomas Hood (jdthood)]

Hi Stéphane.

It was once the case that NM relied on resolvconf's exit status to tell it what it should do next, but in Precise the status was changed to 0, so there is no way that NM can still be using the status to make decisions.

    [ -L /etc/resolv.conf ] || { report_err "/etc/resolv.conf isn't a symlink, not doing anything."; exit 0; }

[Thomas Hood (jdthood)]

Stéphane wrote:
> I'm opening a task for network-manager to update its logic and instead only call resolvconf if /etc/resolv.conf is a symlink to...

I don't see the need for NM ever to refrain from calling resolvconf.

What's best is for everything always to call /sbin/resolvconf if it exists, so that resolvconf always has the best available information, whether or not that is currently directly visible in /etc/resolv.conf.

Callers --- and also callees (hook scripts) --- can _additionally_ look at /etc/resolv.conf and take different actions based on its characteristics, if that's necessary. In Debian resolvconf 1.67, for example, the hook script /etc/resolvconf/update.d/libc looks at /etc/resolv.conf and refrains from running /etc/resolvconf/update-libc.d/* if the latter is not a symlink to the dynamic resolv.conf. Other resolver libraries might legitimately do something similar.

I am not sure, however, what NetworkManager should do (additionally to calling resolvconf) if /etc/resolv.conf is not a standard symlink. Given that the admin may want to change the symlink or put a static file there, NM shouldn't simply overwrite the file. Is there actually any reason for NM to do anything additional?

[Nathan Stratton Treadway (nathanst)]

On Tue, Jun 26, 2012 at 15:58:27 -0000, Thomas Hood wrote:
> Stéphane wrote:
> > I'm opening a task for network-manager to update its logic and instead only call resolvconf if /etc/resolv.conf is a symlink to...
>
> I don't see the need for NM ever to refrain from calling resolvconf.
>
> What's best is for everything always to call /sbin/resolvconf if it
> exists, so that resolvconf always has the best available information,
> whether or not that is currently directly visible in /etc/resolv.conf.

Yes, exactly. (I was just starting to compose a message
saying something similar.)

> I am not sure, however, what NetworkManager should do (additionally to
> calling resolvconf) if /etc/resolv.conf is not a standard symlink.
> Given that the admin may want to change the symlink or put a static file
> there, NM shouldn't simply overwrite the file. Is there actually any
> reason for NM to do anything additional?

I'm not very familiar with the details of NM's operation,
but I gather the point of these exit-status checks, etc. was
to allow NM to continue to maintain /etc/resolv.conf
directly even when the resolvconf package was installed, by
deciding that resolvconf wasn't actually maintaining
/etc/resolv.conf.

Given resolvconf's current higher-profile status, though,
I'm not sure that use-case still applies. I could see the
admin wanting to make /etc/resolv.conf a plain file he/she
controls manually, or wanting to leave it under the standard
control of resolvconf -- but I don't know if there's a
situation where NM needs to be directly managing a
plain-file /etc/resolv.conf itself any more.

(But if there is, it seems like it should be possible to
enable that behavior without disabling resolvconf updating.)

      Nathan

[Stéphane Graber (stgraber)]

Hmm, indeed, I forgot that we are currently returning "exit 0" instead of "exit 1". As nobody seems to be annoyed by that behaviour in Precise, I supposed it's then fine to get rid of that hack in Quantal ;)

Removing the network-manager task and I'll make sure to pick up the fix with the next upload (this week).

[Stéphane Graber (stgraber)]

Hmm, wondering what happened to my network-manager task ;) maybe I added it to the wrong bug? anyway, nothing to remove ;)

[Launchpad Janitor (janitor)]

This bug was fixed in the package resolvconf - 1.67ubuntu1

---------------
resolvconf (1.67ubuntu1) quantal; urgency=low

  * Merge from Debian. Remaining changes:
    (LP: #994575, LP: #999337, LP: #1012355)
    - Make /etc/resolv.conf a relative symlink so that it works when
      setting up chroots.
    - Instead of throwing an error that aborts the upgrade when
      /etc/resolv.conf is immutable, pop a debconf error message to let the
      user know what's happening, then clear the immutable flag and continue
      with the installation. LP: #989585.
    - debian/config, debian/templates, debian/postinst: if we don't know that
      /etc/resolv.conf was being dynamically managed before install (in at
      least some cases), link the original contents of /etc/resolv.conf to
      /etc/resolvconf/resolv.conf.d/tail so that any statically configured
      nameservers aren't lost. LP: #923685.
    - Use an upstart job instead of sysvinit script.
    - Pre-Depend on the /run-providing version of initscripts instead of
      depending, so that the preinst does the right thing when creating
      /run/resolvconf/interfaces instead of getting clobbered later by a bind
      mount on initscripts upgrade. LP: #922491.
    - Completely drop the standard_run_subdirs_created helper function from
      debian/postinst, since it serves no purpose here.
    - postinst: Set resolvconf/linkify-resolvconf to false after initial
      conversion, ensuring upgrades won't convert /etc/resolv.conf to
      a symlink if the user manually converted it back to plain text.
      (LP: #922677)
    - Move the #DEBHELPER# token in debian/postinst to after the resolv.conf
      symlink is set, so the init script can actually start (since it expects
      /etc/resolv.conf to be a symlink).
    - Eliminate all references to /etc/resolvconf/run. This should all be done
      directly in /run, there is no reason to support making any of this
      configurable with a symlink since we already have a versioned dependency
      on the version of initscripts that introduces the /run transition.
    - Also remove debian/triggers to avoid needlessly calling resolvconf's
      postinst. (LP: #931335)
 -- Stephane Graber <email address hidden> Fri, 22 Jun 2012 17:29:50 -0400