GNOME Bugzilla – Bug 227599
DNS issues on change of network
Last modified: 2002-10-10 01:48:13 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: Steps to reproduce the problem: 1. Start out with 1 network configuration. (in my case via DHCP) 2. Suspend laptop, walk down street to another network configured differently. 3. Unsuspend laptop, wait for, or force DHCP to grab new network settings (DNS, IP, etc.) which are different than before. 4. Attempt to fetch email via Evolution. Actual Results: Evolution needs to be restarted after resolv.conf has been updated by DHCP in order to pick up the new settings. Any attempt to fetch mail via Evolution causes it to attempt and fail to find the servers after a very very long timeout. Expected Results: Pick up mail server IPs immediatly -- much as the rest of the system is able to. How often does this happen? Every time I change networks. Additional Information:
this is a libc problem, we do not read /etc/resolv.conf directly, we just use gethostbyname() which is a standard libc function that resolves hostnames for us.
It would be nice if evolution could call res_init() when coming back online to work around this problem. It's a bit difficult to see what the resolver lib is supposed to do. (Check resolv.conf I guess) I haven't tried this (yet), but it sounds like a simple way to work around it.
we've looked into res_init(), and here are our reasons for not using it: 1) res_init() has already been called (it is called by the first call to any res_* functions - of which gethostbyname uses), calling it again is a no-op (libresolv holds state afterall) 2) in order to get res_init() to re-initialise, we must poke extern struct state _res; and unset some flags (this sounds like a portability nightmare to me). If you ignore portability issues, it still leaves you with the question: will re-initialising leak memory? ie, once certain private variables have been initialised (malloc'd and so forth), does res_init() also free those values before re-mallocing new values? Some implementations might, and others might not. Since the man page does not define the behaviour, you must assume the worst. 3) it doesn't work (or at least not in our testing)
I tried this on FreeBSD 4.7-PRE and it does work as I'd expect. I got the patch from someone who wrote it for Solaris, so I presume it works there too. I would not expect a public interface (res_init) to leak memory without explicitly saying so in the man page (which it doesn't). It doesn't work 100% though - If I try and compose or reply to a new message I get CORBA activation failures :( Looks like mangling libc to call res_init from under an application when resolver files change is going to be the least painful way to fix things.