On Mon, Jun 1, 2015 at 12:29 PM, Chris Adams <li...@cmadams.net> wrote: > Once upon a time, Andrew Lutomirski <l...@mit.edu> said: >> I'm with Jason here. Glibc's resolver is amazingly buggy, and things >> break randomly and unreproducibly when this happens. A good setup >> would have a local resolver and glibc would be configured to cache >> nothing whatsoever. Then, if you need to perform maintenance on the >> local DNS cache, you can do it by flushing your local resolver rather >> than trying to figure out how you're going to persuade every running >> program to tell glibc to flush its cache. > > glibc doesn't have a cache, except each process caching the settings in > /etc/resolv.conf. That's part of the problem, because there's no way to > cache "first server in resolv.conf is not responding", so each lookup > has to figure that out for itself (many timeouts).
Glibc caches *something* that enabled the bug I hit. I don't know exactly what it's trying to cache, but it's certainly stateful. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
