Re: [patches] Track resolv.conf, avoid need for explicit res_init() or nscd in long-running applications

[ppluzhnikov@xxxxxxxxxx (Paul Pluzhnikov)]

Greetings,

We've just tracked a bug to this patch:
http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/libc/resolv/res_libc.c?rev=9102&r1=8608&r2=9102

The patch uses a *global* variable to decide whether or not to initialize
a *thread-local* resolver state, which is a bad thing.

On a DHCP-configured machine with no network connection, start an application
with two threads (T1 and T2).

Both T1 and T2 are performing DNS lookups (which are currently failing,
as there is no network yet).

T1 retries every second, T2 retries every minute.

Now the machine gets a connection, and DHCP updates resolv.conf.

T1 discovers that it needs to reinit its state, and updates last_mtime.

Some time later, T2 comes along, and *fails* to reinit its state, since
the file has not been updated after T1 ran and updated last_mtime.

T2 will now fail forever, despite the network being available and working
just fine for T1.

I blieve this patch should be reverted, or last_mtime should be moved into
(thead-local) res_state, so each thread updates its state properly.

Thanks,
--
Paul Pluzhnikov