Re: DNS caching(?) page-hangup issues and Opera 10.X
Eirik Byrkjeflot Anonsen <[email protected]> Mon, 26 Jul 2010 07:06:02 +0200
| Newsgroups | gmane.comp.web.opera.linux |
|---|---|
| Message-ID | <[email protected]> |
Kenneth Crudup <[email protected]> writes: > On Fri, 23 Jul 2010, Daniel Eckl wrote: > >> Could it be that the DNS server of the new network already is the >> second (third, n-th) name server in the old DNS configuration? > > Nah, I use the Ubuntu "network-manager", which does a pretty good job > of keeping the integrity of /etc/resolv.conf . The problem is that the configuration of the resolver (inside libc) isn't updated when /etc/resolv.conf changes. Daniel's thought is that /etc/resolv.conf maybe changes from: nameserver a.b.c.d nameserver e.f.g.h to: nameserver e.f.g.h nameserver i.j.k.l Since libc doesn't realize that the configuration has changed, it will keep sending requests to a.b.c.d. If a.b.c.d is no longer available, there will be no response, and libc may decide to try the other nameserver in the old configuration, e.f.g.h. This nameserver is also available from the new network, and so name lookups work, even though the configuration is still wrong. (e.f.g.h doesn't even have to be mentioned in the new resolv.conf as long as it is accessible on the new network.) > But, and I hate to use this refrain, why doesn't FF suffer from this > issue? They use the exact same libresolv : If the problem really is that libc does not update its configuration when /etc/resolv.conf changes, then this is easily explained: FF already has some code that reloads the configuration. Kenneth Crudup <[email protected]> writes: > On Fri, 23 Jul 2010, Daniel Eckl wrote: > >> For me that sounds if it would not be operas job to do this. I'd more >> say, the OS needs to do this, and since this function is missing, one >> could write a little script and call it via if-up or write a >> (scripted) daemon that watches resolv.conf and then triggers glibc. > > Sometimes running "sudo touch /etc/resolv.conf" seems to help. But I > don't understand why glibc can't detect this on its own. I've seen comments to the effect that glibc fails to update its configuration by choice. I don't know the reasoning behind this, so I can't comment on whether this is the correct choice. But in that case, it is hard to see why touching /etc/resolv.conf should have any effect. (Besides, I would expect that the mtime would be updated when the file was in fact changed anyway...) eirik -- Opera-Linux: https://list.opera.com/mailman/listinfo/opera-linux More lists: https://list.opera.com/mailman/listinfo/ Unsubscribe: mailto:[email protected]?subject=unsubscribe