Bug 3675 - libc caches resolv.conf forever
Summary: libc caches resolv.conf forever
Status: CLOSED DUPLICATE of bug 984
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.3.5
: P2 critical
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-07 14:38 UTC by Matthias Andree
Modified: 2015-05-15 20:37 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Andree 2006-12-07 14:38:27 UTC
Relevant libc extension: BIND-8.2.3-T5B

libc apparently reads /etc/resolv.conf upon the first access to getaddrinfo()
and parses it and continues with the parsed results forever, even if
/etc/resolv.conf changes. There is no documented interface to cause libc to
re-read the resolv.conf file.

Real-world problem: Processes designed to run for many days will not detect
resolv.conf changes. On systems without permanent internet connection,
resolv.conf may be rewritten by unrelated DHCP client or PPP peer software after
an application using getaddrinfo() has started. The result is that errors such
as EAI_AGAIN that stem from stale /etc/resolv.conf parsed at application
start-up time persist until the application terminates.

Suggested solution: be sure to check /etc/resolv.conf for changes and, when
changes are detected, re-parse it every few (say, 5) seconds, or when EAI_AGAIN
would be returned. The time limit should bound the amount of time spent parsing
said fail without introducing too much delay WRT picking up changes.

Checking for resolv.conf changes upon EAI_AGAIN is clearly my favorite.
Comment 1 Ulrich Drepper 2006-12-07 15:17:32 UTC
That's what res_init() is for, call it.
Comment 2 Matthias Andree 2006-12-07 15:22:18 UTC
Thank you. Could you confirm that res_init() does:

- *not* look at the RES_INIT state (i. e. re-reads resolv.conf every time it is
called), and
- *not* leak memory when called frequently?
Comment 3 Florian Weimer 2015-05-15 20:37:07 UTC
This was also reported as bug 984.

*** This bug has been marked as a duplicate of bug 984 ***