<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I recently opened a bug with glibc because persistent programs (like
Thunderbird, etc) don't seem to handle roaming onto different
networks very well.<br>
<br>
Or rather, they rely on libresolv which opens /etc/resolv.conf at
startup and then ignores changes to the file for the rest of the
time the process it is linked to is running.<br>
<br>
This might have been fine for desktop tower computers in the 1980's
(though even then we had PPP and dynamic network settings), but
we're in the era of pervasive laptops with internet connections and
you're settings are going to be volatile. Period.<br>
<br>
It's naive of a vital library like libresolv to assume either that
(1) the process it's running in is going to be short-lived or (2)
that the network isn't dynamic and that nameserver settings (and the
default domain and domain search path, i.e. basically everything in
/etc/resolv.conf) isn't going to change. (For those who've never
looked too closely, /etc/resolv.conf gets rewritten by ISC's
dhclient when new DHCP settings are received which includes a domain
name, domain search path, or server addresses.)<br>
<br>
Here's the bug I've opened:<br>
<br>
<a class="moz-txt-link-freetext" href="https://sourceware.org/bugzilla/show_bug.cgi?id=18279">https://sourceware.org/bugzilla/show_bug.cgi?id=18279</a><br>
<br>
If you go back through the previous glibc bugs, you'll find:<br>
<br>
<a class="moz-txt-link-freetext" href="https://sourceware.org/bugzilla/show_bug.cgi?id=984">https://sourceware.org/bugzilla/show_bug.cgi?id=984</a><br>
<br>
from 2005 which was closed out as "RESOLVED, WONTFIX" with the text:<br>
<blockquote>There is a solution, already implemented.<br>
Use nscd and nscd -i hosts in the script that rewrites your
resolv.conf<br>
(or nsswitch.conf etc.).<br>
</blockquote>
Problem with that is that no one seems to have gravitated towards
this solution, and I don't blame them. It adds an extra layer of
complexity and makes debugging issues that much more murky.<br>
<br>
A simpler fix is to grab mtime from stat()ing _PATH_RESCONF each
time through res_query() and see if it's changed since the last
time. Perhaps caching the inode # also and checking that, since an
older version of the file might have been renamed as
/etc/resolv.conf.<br>
<br>
Or one could use inotify(), but that's a whole lot less portable.<br>
<br>
One obvious pitfall is multi-threading: it's a possibility that
res_init() got called by the main thread before additional worker
threads got created, in which case calling res_init subsequent times
becomes a little more hairy.<br>
<br>
I suspect that bug #18279 might come to the same fate as #984, but I
hope not: the network and the way that we use it have both evolved
these last 10 years, and let's hope that the way the glibc
maintainers view both has also changed.<br>
<br>
Please add yourself to this bug and if the glibc folks try to argue
for closing it, perhaps someone out there has a more compelling
argument than I do.<br>
<br>
Thanks,<br>
<br>
-Philip<br>
<br>
</body>
</html>