On Fri, Jan 02, 2004 at 09:33:15PM -0500, Greg A. Woods wrote:
> [ On Saturday, January 3, 2004 at 02:47:09 (+0100), Manuel Bouyer wrote: ]
> > Subject: Re: re-reading /etc/resolv.conf on change
> >
> > You forgot from where this thread started. I hacked on this because I was
> > annoyed by the behavior when I switched from linux netscape4 (which manages to
> > reread resolv.conf is a way or another) to native mozilla.
> 
> Well, no, I didn't forget.
> 
> I've simply been focusing on the intermediate points others have raised.
> 
> netscape4 undoutably just called res_init() to reload /etc/resolv.conf,
> though I've no idea how it decided when to do so.

I don't have the sources of netscape4, and didn't look at the glibc sources
used by the binary.

> 
> I've you've taken any time to investigate this issue with mozilla I
> think you'll find many patches and suggestions for fixing it.  None of
> them involve modifying the resolver library itself.  Some use the silly
> hack of turning of the internal RES_INIT flag before _every_ call to a
> high-level function such as gethostbyname(), which will of course cause
> that function to call res_init() again; and some of them hope to rely on
> glibc specific features.  They should just use res_init() in a timely
> fashion, but they have, or at least had, some serious concurrency bugs
> in their threading model and were not restricting DNS lookups to a
> single thread.
> 
> The related problems with Mozilla include (but are most certainly _not_
> limited to):  (a) its developers are far too enamoured with glibc; and
> (b) it's developers are not really well trained in writing safe and
> reliable threaded applications.
> 
> Regardless hacking the resolver code in some vain attempt to solve this
> problem for the application is still the wrong solution.

remplace mozilla with any other web browser, MUA or news reader.
It's silly to go fix each applications when we could do it in one
centralised place, and get consistent behavior of all applications.

> 
> The best solution for you for now really is to run your own caching
> daemon since after all you're not afraid of large-footprint programs if
> you're already running Mozilla.

As already pointed out, a local caching nameserver isn't always an option,
and in my case I don't want it. In addition, some internet tools only
know how to change resolv.conf, not the nameserver config.

> 
> 
> > A web browser don't react the way you descrive to SIGHUP, and I don't expect
> > it to. For such a software, exiting gracefully on SIGUP is probably the right
> > thing.
> 
> You're also focusing on the wrong thing.  SIGHUP is _only_ an _example_!!!!

So you're proposing to have each application implement its own hack for this,
with different behavior between applications ?

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--