[Bug 1110331] [NEW] Enhance glibc to monitor mtime of resolv.conf

Thomas Hood 1110331 at bugs.launchpad.net
Wed Jan 30 11:42:05 UTC 2013


Public bug reported:

Browsing the eglibc mailing list archives I notice[0] that the eglibc
resolver has been enhanced[1] such that if /etc/resolv.conf's mtime
changes then the client is asked to re-initialize the resolver state. I
haven't tested the code, but if I understand the feature correctly it
gives us an opportunity to eliminate from /etc/resolvconf/update.d/libc
the code that restarts nscd. That would be a desirable simplification.
Ditto for some other resolvconf update scripts.

We can't go ahead and eliminate the nscd-restart code yet for a simple
reason. The eglibc resolver monitors /etc/resolv.conf and thus watches
the mtime of the symlink, not the target, whereas of course resolvconf
modifies the target.[2]

                ret = stat (_PATH_RESCONF, &statbuf);
                [...]
                if ((ret == 0) && (last_mtime != statbuf.st_mtime)) {
                        last_mtime = statbuf.st_mtime;
                        atomicinc (__res_initstamp);
                }

The first question is, can we take advantage of this eglibc enhancement
in order to simplify resolvconf update scripts?  Second question: do we
want to?

If so, then the third question is, what's the best way to enhance the
new eglibc feature so that we can take advantage of it? Should the
eglibc code be changed so that, in addition to noticing a change in the
mtime of /etc/resolv.conf, it also notices a change in the mtime of the
target of /etc/resolv.conf if the latter is a symbolic link?

[0]http://www.eglibc.org/archives/patches/msg00977.html
[1]http://patch-tracker.debian.org/patch/series/view/eglibc/2.11.3-4/any/submitted-resolv.conf-thread.diff
[2]Quoted code is at line 102 of resolv/res_libc.c

** Affects: resolvconf (Ubuntu)
     Importance: Undecided
         Status: New

-- 
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/1110331

Title:
  Enhance glibc to monitor mtime of resolv.conf

Status in “resolvconf” package in Ubuntu:
  New

Bug description:
  Browsing the eglibc mailing list archives I notice[0] that the eglibc
  resolver has been enhanced[1] such that if /etc/resolv.conf's mtime
  changes then the client is asked to re-initialize the resolver state.
  I haven't tested the code, but if I understand the feature correctly
  it gives us an opportunity to eliminate from
  /etc/resolvconf/update.d/libc the code that restarts nscd. That would
  be a desirable simplification. Ditto for some other resolvconf update
  scripts.

  We can't go ahead and eliminate the nscd-restart code yet for a simple
  reason. The eglibc resolver monitors /etc/resolv.conf and thus watches
  the mtime of the symlink, not the target, whereas of course resolvconf
  modifies the target.[2]

                  ret = stat (_PATH_RESCONF, &statbuf);
                  [...]
                  if ((ret == 0) && (last_mtime != statbuf.st_mtime)) {
                          last_mtime = statbuf.st_mtime;
                          atomicinc (__res_initstamp);
                  }

  The first question is, can we take advantage of this eglibc
  enhancement in order to simplify resolvconf update scripts?  Second
  question: do we want to?

  If so, then the third question is, what's the best way to enhance the
  new eglibc feature so that we can take advantage of it? Should the
  eglibc code be changed so that, in addition to noticing a change in
  the mtime of /etc/resolv.conf, it also notices a change in the mtime
  of the target of /etc/resolv.conf if the latter is a symbolic link?

  [0]http://www.eglibc.org/archives/patches/msg00977.html
  [1]http://patch-tracker.debian.org/patch/series/view/eglibc/2.11.3-4/any/submitted-resolv.conf-thread.diff
  [2]Quoted code is at line 102 of resolv/res_libc.c

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




More information about the foundations-bugs mailing list