gethostbyname() and resolv.conf updates

[Bernie Innocenti]

Hello,

xchat in Fedora needs to be restarted after switching to a different
nameserver or it fails to resolve.

The xchat developers say that all xchat does is call gethostbyname(). A
Debian user told me that Debian carries a glibc patch to make processes
notice resolv.conf updates and reload it.

Is there any chance we could apply the same patch in Fedora too? I don't
know all the details, but I guess there might be a good reason why this
patch wasn't upstreamed yet.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/

[Jason L Tibbitts III]

> >>>> "BI" == Bernie Innocenti
> <bernie(a)codewiz.org&gt; writes: 
BI> A Debian user told me that Debian carries a glibc patch to make
BI> processes notice resolv.conf updates and reload it.  Is there any
BI> chance we could apply the same patch in Fedora too? I don't know all
BI> the details, but I guess there might be a good reason why this patch
BI> wasn't upstreamed yet.

Well, it never hurts to search bugzilla.

https://bugzilla.redhat.com/show_bug.cgi?id=442172 is, I believe, on
point.  There's also
https://bugzilla.redhat.com/show_bug.cgi?id=565880.  However, I'm not
sure if or how sssd makes any difference here.

 - J<

[Roland McGrath]

nscd and sssd exist in part exactly to address this issue.

[Michal Schmidt]

On Thu, 17 Jun 2010 17:41:27 -0400 Bernie Innocenti wrote:
>  xchat in Fedora needs to be restarted after switching to a different
>  nameserver or it fails to resolve.
>  
>  The xchat developers say that all xchat does is call gethostbyname().
>  A Debian user told me that Debian carries a glibc patch to make
>  processes notice resolv.conf updates and reload it.
>  
>  Is there any chance we could apply the same patch in Fedora too? I
>  don't know all the details, but I guess there might be a good reason
>  why this patch wasn't upstreamed yet. 
Ulrich Drepper always said resolv.conf updates are detected fine when
nscd is running, and that everyone should use it. There's a bug
requesting nscd to be mandatory:
https://bugzilla.redhat.com/show_bug.cgi?id=565880

Michal

[Stephen Gallagher]

On 06/17/2010 06:05 PM, Michal Schmidt wrote:
>  On Thu, 17 Jun 2010 17:41:27 -0400 Bernie Innocenti wrote:
> > xchat in Fedora needs to be restarted after switching to a different
> > nameserver or it fails to resolve.
> >
> > The xchat developers say that all xchat does is call gethostbyname().
> > A Debian user told me that Debian carries a glibc patch to make
> > processes notice resolv.conf updates and reload it.
> >
> > Is there any chance we could apply the same patch in Fedora too? I
> > don't know all the details, but I guess there might be a good reason
> > why this patch wasn't upstreamed yet.
>
>  Ulrich Drepper always said resolv.conf updates are detected fine when
>  nscd is running, and that everyone should use it. There's a bug
>  requesting nscd to be mandatory:
>  https://bugzilla.redhat.com/show_bug.cgi?id=565880
>
>  Michal 
NSCD should absolutely NOT be mandatory. There are many reasons not to 
run it (for example, maybe you actually want your identity lookups to be 
sane). NSCD provides unreliable (and occasionally unpredictable) 
behavior in identity caching. This is one of the reasons that the SSSD 
is being written to replace it. It is strongly advised NOT to run the 
SSSD and NSCD simultaneously (Things will still run, but NSCD will be 
acting as an additional cache, eliminating the predictability of the 
SSSD cache)

-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

[Huzaifa Sidhpurwala]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernie Innocenti wrote:
>  Hello,
>  
>  xchat in Fedora needs to be restarted after switching to a different
>  nameserver or it fails to resolve.
>  
>  The xchat developers say that all xchat does is call gethostbyname(). A
>  Debian user told me that Debian carries a glibc patch to make processes
>  notice resolv.conf updates and reload it.
>  
>  Is there any chance we could apply the same patch in Fedora too? I don't
>  know all the details, but I guess there might be a good reason why this
>  patch wasn't upstreamed yet.
>   
I dont think we should patch glibc, unless its upstream.
Looking at the thread at:
http://sources.redhat.com/ml/libc-alpha/2004-09/msg00109.html
it does not appear this patch would make it upstream though.



- --
Regards,
Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)

GnuPG Fingerprint:
3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/
>
> iD8DBQFMGudszHDc8tpb2uURApicAJsFY4D+T59/oLPCMpsPuYMQX4xVVACeK589
> 3YToGCKcXX0OO8OkqKJJlw8=
> =USCv
> -----END PGP SIGNATURE-----

[Stephen Gallagher]

On 06/17/2010 05:41 PM, Bernie Innocenti wrote:
>  Hello,
>
>  xchat in Fedora needs to be restarted after switching to a different
>  nameserver or it fails to resolve.
>
>  The xchat developers say that all xchat does is call gethostbyname(). A
>  Debian user told me that Debian carries a glibc patch to make processes
>  notice resolv.conf updates and reload it.
>
>  Is there any chance we could apply the same patch in Fedora too? I don't
>  know all the details, but I guess there might be a good reason why this
>  patch wasn't upstreamed yet.
>  
This is the entire purpose of the res_init() function in glibc. If your 
application needs to be aware of a change in resolv.conf, you should be 
monitoring it with inotify and calling res_init() anytime the file is 
changed.

I disagree that this is necessarily a bug in glibc, as it allows the 
application writer to decide for themselves whether to trust a change to 
resolv.conf mid-operation.

The easy fix in xchat would be to simply call res_init() immediately 
before calling gethostbyname(). It would add a small amount of overhead 
to hostname lookups, but it would always work. Monitoring resolv.conf 
for changes would be an optimization, of course.

-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

[Colin Walters]

On Fri, Jun 18, 2010 at 8:23 AM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  This is the entire purpose of the res_init() function in glibc. If your
>  application needs to be aware of a change in resolv.conf, you should be
>  monitoring it with inotify and calling res_init() anytime the file is
>  changed. 
That's awful.  Really, really awful.  Do you have any idea how many
things would need to be patched to do that?  Other operating systems
handle this just fine.  Asking every component to use inotify and
res_init() because the glibc maintainers apparently think a simple
stat() on a sure-to-be-in-kernel cache inode is too expensive...well,
think about it.

[Stephen Gallagher]

On 06/18/2010 09:43 AM, Colin Walters wrote:
>  On Fri, Jun 18, 2010 at 8:23 AM, Stephen
> Gallagher<sgallagh(a)redhat.com>  wrote:
> >
> > This is the entire purpose of the res_init() function in glibc. If your
> > application needs to be aware of a change in resolv.conf, you should be
> > monitoring it with inotify and calling res_init() anytime the file is
> > changed.
>
>  That's awful.  Really, really awful.  Do you have any idea how many
>  things would need to be patched to do that?  Other operating systems
>  handle this just fine.  Asking every component to use inotify and
>  res_init() because the glibc maintainers apparently think a simple
>  stat() on a sure-to-be-in-kernel cache inode is too expensive...well,
>  think about it. 
Sorry, my reply was more directed against the assertion that NSCD should 
be mandatory to solve this without changes to glibc. I agree that it 
would be ideal for gethostbyname() to internally perform a res_init() 
when appropriate.

-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

[Colin Walters]

On Fri, Jun 18, 2010 at 9:56 AM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  Sorry, my reply was more directed against the assertion that NSCD should
>  be mandatory to solve this without changes to glibc. I agree that it
>  would be ideal for gethostbyname() to internally perform a res_init()
>  when appropriate. 
Ok, then we agree.  I don't personally care whether it's NSCD or a
magical oracle as long as our operating system's gethostbyname()
function actually functions on mobile devices.  (Caching DNS would be
a huge bonus, as other operating systems do this and us not doing so
makes the internet "feel" significantly, visibly slower compared to
them, but that's a separate bug)

[Stephen Gallagher]

On 06/18/2010 09:59 AM, Colin Walters wrote:
>  On Fri, Jun 18, 2010 at 9:56 AM, Stephen
> Gallagher<sgallagh(a)redhat.com>  wrote:
> >
> > Sorry, my reply was more directed against the assertion that NSCD should
> > be mandatory to solve this without changes to glibc. I agree that it
> > would be ideal for gethostbyname() to internally perform a res_init()
> > when appropriate.
>
>  Ok, then we agree.  I don't personally care whether it's NSCD or a
>  magical oracle as long as our operating system's gethostbyname()
>  function actually functions on mobile devices.  (Caching DNS would be
>  a huge bonus, as other operating systems do this and us not doing so
>  makes the internet "feel" significantly, visibly slower compared to
>  them, but that's a separate bug) 
Well, I definitely care that it's not NSCD, as NSCD is such a broken 
caching mechanism that basically everyone turns it off in any 
environment where reliable caching is needed (and is also a large part 
of the reason SSSD was developed - to produce a stable cache).

If we start asserting that everyone has to use NSCD in order to get 
stable gethostbyname(), then clearly someone is missing the point.
-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

[Dan Williams]

On Fri, 2010-06-18 at 09:59 -0400, Colin Walters wrote:
>  On Fri, Jun 18, 2010 at 9:56 AM, Stephen Gallagher
> <sgallagh(a)redhat.com&gt; wrote:
>  >
>  > Sorry, my reply was more directed against the assertion that NSCD should
>  > be mandatory to solve this without changes to glibc. I agree that it
>  > would be ideal for gethostbyname() to internally perform a res_init()
>  > when appropriate.
>  
>  Ok, then we agree.  I don't personally care whether it's NSCD or a
>  magical oracle as long as our operating system's gethostbyname()
>  function actually functions on mobile devices.  (Caching DNS would be
>  a huge bonus, as other operating systems do this and us not doing so
>  makes the internet "feel" significantly, visibly slower compared to
>  them, but that's a separate bug) 
I'm just gonna make NM use a local caching nameserver (which means
dnsmasq) by default at some point soon.  People that don't want it can
turn it off.

Dan

[Colin Walters]

On Sat, Jun 19, 2010 at 10:54 PM, Dan Williams <dcbw(a)redhat.com&gt; wrote:
>  I'm just gonna make NM use a local caching nameserver (which means
>  dnsmasq) by default at some point soon.  People that don't want it can
>  turn it off. 
When thinking about this, there's a rather obvious patch here that
really should have been made 5+ years ago...make it an option!  And
this actually makes some sense, e.g. if NetworkManager writes out a
static configuration, then there's no need to stat() on it since we
can assume it won't change.  (This does still screw over server admins
who hand-edit it, but...)

glibc and NetworkManager patches attached.

(I'm totally in favor of the dnsmasq approach too since the OS
desperately needs DNS caching too, but this is a simple patch that
doesn't conceptually conflict).

[Pádraig Brady]

On 21/06/10 15:40, Colin Walters wrote:
>  On Sat, Jun 19, 2010 at 10:54 PM, Dan Williams
> <dcbw(a)redhat.com&gt; wrote:
> >
> > I'm just gonna make NM use a local caching nameserver (which means
> > dnsmasq) by default at some point soon.  People that don't want it can
> > turn it off.
>  
>  When thinking about this, there's a rather obvious patch here that
>  really should have been made 5+ years ago...make it an option!  And
>  this actually makes some sense, e.g. if NetworkManager writes out a
>  static configuration, then there's no need to stat() on it since we
>  can assume it won't change.  (This does still screw over server admins
>  who hand-edit it, but...)
>  
>  glibc and NetworkManager patches attached.
>  
>  (I'm totally in favor of the dnsmasq approach too since the OS
>  desperately needs DNS caching too, but this is a simple patch that
>  doesn't conceptually conflict). 
Sorry I haven't been following this really, but I loath
config options that aren't absolutely required, and this
seems like a place where we could just stat() (cache) always.
What's the problem with doing that?

Are we worried about the performance of doing time()
for every request? I would never expect anything
resembling efficiency from DHCP, never mind the
overhead of a time() call.
Has debian ever had complaints given that they
patch glibc by default?

cheers,
Pádraig.

p.s. not having looked at the code,
the atomic ops seems unusual in the
presence of the static last_... variables.

[Colin Walters]

2010/6/21 Pádraig Brady <P(a)draigbrady.com&gt;:
>  Sorry I haven't been following this really, but I loath
>  config options that aren't absolutely required, and this
>  seems like a place where we could just stat() (cache) always.
>  What's the problem with doing that? 
I too would be really interested in any real-world application for
which the cost of the stat() was any kind of major performance hit.

>  p.s. not having looked at the code,
>  the atomic ops seems unusual in the
>  presence of the static last_... variables. 
We are implicitly relying on aligned word size assignment atomicity
here it looks like, yes.  I haven't looked if there are other places
in glibc doing this or if there's some infrastructure for it.  To be
clear this patch is derived from the OpenSUSE one; I didn't change the
semantics there.

[Nicolas Chauvet]

2010/6/17 Bernie Innocenti <bernie(a)codewiz.org&gt;:
>  Hello,
>
>  xchat in Fedora needs to be restarted after switching to a different
>  nameserver or it fails to resolve.
>
>  The xchat developers say that all xchat does is call gethostbyname(). A 
There was a
topic 3 years ago  about replacing gethostby* functions by
getaddrinfo
Is this still relevant?

http://lists.fedoraproject.org/pipermail/devel/2007-October/112483.html
http://udrepper.livejournal.com/16116.html

Nicolas (kwizart)

[Dan Winship]

On 06/20/2010 04:41 AM, Nicolas Chauvet wrote:
>  2010/6/17 Bernie Innocenti <bernie(a)codewiz.org&gt;:
> > Hello,
> >
> > xchat in Fedora needs to be restarted after switching to a different
> > nameserver or it fails to resolve.
> >
> > The xchat developers say that all xchat does is call gethostbyname(). A
>  There was a topic 3 years ago  about replacing gethostby* functions by
>  getaddrinfo
>  Is this still relevant? 
You definitely still want to replace gethostbyname with getaddrinfo,
because gethostbyname can't handle IPv6 addresses. But that's not
relevant to this particular problem (noticing resolv.conf updates)
because both functions use the same internal glibc methods, they just
package the results differently.

-- Dan