----- Original Message -----
From: "Dan Fandrich" <dan_at_coneharvesters.com>
To: <curl-library_at_lists.sourceforge.net>
Sent: Wednesday, February 04, 2004 7:04 PM
Subject: Re: curl/c-ares problem with a chroot'ed program

> On Wed, Feb 04, 2004 at 06:32:18PM -0500, codemastr wrote:
> > Ok here's the problem. libcurl calls ares_init() in Curl_addrinfo().
> > Curl_addrinfo() is called for each download. Here is the problem,
> > ares_init() loads /etc/resolv.conf. Once my program does chroot(),
> > /etc/resolv.conf is now "outside the root" and therefore inaccessible.
As a
> > result, c-ares and libcurl can no longer determine my nameserver info.
> >
> > There is a solution I've come up with that is the best I can think of.
> > (maybe someone can come up with a better method of implementation).
> >
> > CURL_GLOBAL_ARES. If this is set in curl_global_init, then curl will
call
> > ares_init, store the results in a global var (could result in threading
> > issues, though this global var should never be modified, only read
therefore
> > I can't forsee any...), then Curl_addrinfo() will no longer call
> > ares_init(), instead, it will simply use this global var.
> >
> > If CURL_GLOBAL_ARES is _not_ specified then everything works as it
currently
> > does.
> >
> > This should solve the problem since as long as I call curl_global_init
> > before chroot(), curl will store the resolv.conf info and it will work.
This
> > also serves to make things faster since it doesn't have to read a file
(or
> > on win look in the registry) each time a DNS query is to be made...
> >
> > Suggestions/comments?
>
> This proposed solution will have a problem with long-running apps on
> hosts with DHCP-assigned IP addressies or portable hosts. If a new DNS
> address is configured in /etc/resolv.conf due to a DHCP lease expiring or
a
> laptop user moving into a new WiFi hotspot (for example) then libcurl
could
> stop resolving hosts. There has to be some way to check for changes in
> /etc/resolv.conf at run time. It doesn't necessarily have to be on every
> lookup; it may be good enough in practise to reload it just when a lookup
> fails.

Well that's true but it doesn't solve my problem because then it will reload
the new resolv.conf and fail. But even so, to my knowledge, gethostbyname()
doesn't check if resolv.conf has changed, and I've never seen any app that
checks it so frequently. I don't know why libcurl has to... I mean, ares
doesn't include that code in its lookup routine, it's in the init function.
libcurl is the one that does it at each lookup.

Dominick Meglio

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
Received on 2004-02-05