On Wed May 26 2010 14:25:59 Dima Q wrote:
> I found out a workaround, I can create a short-lived curl object every
> now and again and run a request to the same hostname through that. This
> curl object creates new channel with c-ares, which loads new resolv.conf
> and updates dns cache.
>
> It works for the long-lived process only because I use a curl share to
> cache dns and cookies.
> If I didn't use curl share, I would need to cleanup and re-init the
> "main" curl object.
>
> I looked at the circumbstances where init_by_resolv_conf is called or
> could be called in c-ares, and I realized that to make a proper patch I
> would either need to change curl as well as change c-ares a little bit,
> or change c-ares a lot.
> The earlier seems very similar to what's already on curl TODO,
> The latter is more robust but I doubt I could test it well enough.
>
> Howard, I've seen similar arguments, gnu libc folks used at least since
> 2004 and yet modern distros (tested gentoo and ubuntu) somehow managed
> to work around this, evident in strace output for curl built with glibc
> resolver - there is 1 (or sometimes 2) stat64("/etc/resolv.conf") for
> each request that opens a new socket. Not so with c-ares.
>
> I think c-ares should be at least as good as glibc resolver, not worse.

I think we were facing exactly same problem with the caching
of /etc/resolv.conf in Fedora installer recently:

https://bugzilla.redhat.com/562209

As for the glibc resolver, the solution is to call res_init(3), in order
to invalidate the cache. As for c-ares, there is probably no solution for
now. Only some workarounds, as you can see in the referred bug.

Kamil
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-05-26