[Bug 1012355] Re: /sbin/resolvconf shouldn't abort when /etc/resolv.conf is not a symlink

[Nathan Stratton Treadway]

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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1012355

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

Status in “resolvconf” package in Ubuntu:
  In Progress
Status in “resolvconf” source package in Quantal:
  In Progress

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1012355/+subscriptions