Sourceware Bugzilla – Attachment 9078 Details for
Bug 984
Respond to changed resolv.conf in gethostbyname
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
attachment-37701-0.html
attachment-37701-0.html (text/html), 2.33 KB, created by
Karl
on 2016-03-09 05:17:15 UTC
(
hide
)
Description:
attachment-37701-0.html
Filename:
MIME Type:
Creator:
Karl
Created:
2016-03-09 05:17:15 UTC
Size:
2.33 KB
patch
obsolete
>This sounds like a great solution!!!<br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 8, 2016 at 9:07 PM ebiggers3 at gmail dot com <<a href="mailto:sourceware-bugzilla@sourceware.org">sourceware-bugzilla@sourceware.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="https://sourceware.org/bugzilla/show_bug.cgi?id=984" rel="noreferrer" target="_blank">https://sourceware.org/bugzilla/show_bug.cgi?id=984</a><br> ><br> >Eric Biggers <ebiggers3 at gmail dot com> changed:<br> ><br> >      What  |Removed           |Added<br> >----------------------------------------------------------------------------<br> >         CC|              |ebiggers3 at gmail dot com<br> ><br> >--- Comment #11 from Eric Biggers <ebiggers3 at gmail dot com> ---<br> >Please consider for inclusion in glibc the stat() patch used by Debian. I<br> >recently spent a long time tracking down a problem with hostname resolution in<br> >a long-running process which ultimately turned out to be caused by glibc<br> >caching an empty /etc/resolv.conf. This can occur if the network configuration<br> >is dynamic, e.g. managed by DHCP and NetworkManager. From googling, it's<br> >apparent that many different programs, such as web browsers (Firefox, Chromium,<br> >etc.), have also run into this problem and have had to add hacks to work around<br> >it.<br> ><br> >Interestingly, in contrast with /etc/resolv.conf, glibc's resolver immediately<br> >recognizes changes in /etc/hosts. Furthermore, /etc/hosts is always read in<br> >full. It seems that if there is concern about performance of stat()ing<br> >/etc/resolv.conf, there could be an optimization made to skip reading<br> >/etc/hosts if it hasn't changed, thereby replacing about 5 system calls with 1.<br> > That would likely save more time per getaddrinfo() than is spent by stat()ing<br> >/etc/resolv.conf an extra time.<br> ><br> >Of course, the "correct" solution would be to use inotify to push changes only<br> >when they actually happen. Unfortunately, glibc doesn't have an opportunity to<br> >do that.<br> ><br> >--<br> >You are receiving this mail because:<br> >You are on the CC list for the bug.</blockquote></div>
This sounds like a great solution!!!<br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 8, 2016 at 9:07 PM ebiggers3 at gmail dot com <<a href="mailto:sourceware-bugzilla@sourceware.org">sourceware-bugzilla@sourceware.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="https://sourceware.org/bugzilla/show_bug.cgi?id=984" rel="noreferrer" target="_blank">https://sourceware.org/bugzilla/show_bug.cgi?id=984</a><br> <br> Eric Biggers <ebiggers3 at gmail dot com> changed:<br> <br>       What  |Removed           |Added<br> ----------------------------------------------------------------------------<br>          CC|              |ebiggers3 at gmail dot com<br> <br> --- Comment #11 from Eric Biggers <ebiggers3 at gmail dot com> ---<br> Please consider for inclusion in glibc the stat() patch used by Debian. I<br> recently spent a long time tracking down a problem with hostname resolution in<br> a long-running process which ultimately turned out to be caused by glibc<br> caching an empty /etc/resolv.conf. This can occur if the network configuration<br> is dynamic, e.g. managed by DHCP and NetworkManager. From googling, it's<br> apparent that many different programs, such as web browsers (Firefox, Chromium,<br> etc.), have also run into this problem and have had to add hacks to work around<br> it.<br> <br> Interestingly, in contrast with /etc/resolv.conf, glibc's resolver immediately<br> recognizes changes in /etc/hosts. Furthermore, /etc/hosts is always read in<br> full. It seems that if there is concern about performance of stat()ing<br> /etc/resolv.conf, there could be an optimization made to skip reading<br> /etc/hosts if it hasn't changed, thereby replacing about 5 system calls with 1.<br>  That would likely save more time per getaddrinfo() than is spent by stat()ing<br> /etc/resolv.conf an extra time.<br> <br> Of course, the "correct" solution would be to use inotify to push changes only<br> when they actually happen. Unfortunately, glibc doesn't have an opportunity to<br> do that.<br> <br> --<br> You are receiving this mail because:<br> You are on the CC list for the bug.</blockquote></div>
View Attachment As Raw
Actions:
View
Attachments on
bug 984
: 9078