This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug network/984] Respond to changed resolv.conf in gethostbyname


https://sourceware.org/bugzilla/show_bug.cgi?id=984

--- Comment #12 from Karl <karl at thefrenches dot us> ---
This sounds like a great solution!!!
On Tue, Mar 8, 2016 at 9:07 PM ebiggers3 at gmail dot com <
sourceware-bugzilla@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=984
>
> Eric Biggers <ebiggers3 at gmail dot com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |ebiggers3 at gmail dot com
>
> --- Comment #11 from Eric Biggers <ebiggers3 at gmail dot com> ---
> Please consider for inclusion in glibc the stat() patch used by Debian.  I
> recently spent a long time tracking down a problem with hostname
> resolution in
> a long-running process which ultimately turned out to be caused by glibc
> caching an empty /etc/resolv.conf.  This can occur if the network
> configuration
> is dynamic, e.g. managed by DHCP and NetworkManager.  From googling, it's
> apparent that many different programs, such as web browsers (Firefox,
> Chromium,
> etc.), have also run into this problem and have had to add hacks to work
> around
> it.
>
> Interestingly, in contrast with /etc/resolv.conf, glibc's resolver
> immediately
> recognizes changes in /etc/hosts.  Furthermore, /etc/hosts is always read
> in
> full.  It seems that if there is concern about performance of stat()ing
> /etc/resolv.conf, there could be an optimization made to skip reading
> /etc/hosts if it hasn't changed, thereby replacing about 5 system calls
> with 1.
>  That would likely save more time per getaddrinfo() than is spent by
> stat()ing
> /etc/resolv.conf an extra time.
>
> Of course, the "correct" solution would be to use inotify to push changes
> only
> when they actually happen.  Unfortunately, glibc doesn't have an
> opportunity to
> do that.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]