This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug network/984] Respond to changed resolv.conf in gethostbyname
- From: "karl at thefrenches dot us" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 09 Mar 2016 05:17:13 +0000
- Subject: [Bug network/984] Respond to changed resolv.conf in gethostbyname
- Auto-submitted: auto-generated
- References: <bug-984-131 at http dot sourceware dot org/bugzilla/>
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.