I recently opened a bug with glibc because persistent programs (like Thunderbird, etc) don't seem to handle roaming onto different networks very well.
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. 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. 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.) Here's the bug I've opened: https://sourceware.org/bugzilla/show_bug.cgi?id=18279 If you go back through the previous glibc bugs, you'll find: https://sourceware.org/bugzilla/show_bug.cgi?id=984 from 2005 which was closed out as "RESOLVED, WONTFIX" with the text: There is a solution, already implemented. Use nscd and nscd -i hosts in the script that rewrites your resolv.conf (or nsswitch.conf etc.). 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. 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. Or one could use inotify(), but that's a whole lot less portable. 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. 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. 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. Thanks, -Philip
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
