On Feb 5, 1:10, Dominick Meglio wrote:
[..]
>From: "Dan Fandrich" <dan_at_coneharvesters.com>
[...]
>> 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.

FWIW, I believe you are right about gethostbyname(). The manpage for
resolve.conf says: ".. The resolver configuration file contains information
that is read by the resolver routines the first time they are invoked by a
process."

That been said, chroot'ed environments will as a general rule have to make
sure that everything it needs is, in fact, available inside the chroot'ed
environment itself. Sometimes hard links can help, e.g.
ln /etc/resolv.conf /chroot/etc/resolv.conf or something.

-Tor

-------------------------------------------------------
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