Looking further into the resolver code, I don't see the
glibc resolver looking at the RES_TIMEOUT environment
variable. It only seems to look for the RES_OPTIONS
environment variable into which it looks for the tokens
ndots, debug and inet6.
The delay seems to come from the 4 retrys set by the lines
if (!_res.retry)
_res.retry = 4;
in res_init.
_res is defined as:
/*
* Resolver state default settings.
*/
struct __res_state _res
# if defined(__BIND_RES_TEXT)
= { RES_TIMEOUT, } /* Motorola, et al. */
# endif
;
so, if you can set the retry field of this structure to non-zero
before res_init gets called, probably when the resolver gets
used for the first time, you should be able to adjust the number
of retrys.
The polling for the reply is hardcoded 1 second, so all you can
tinker with is the number of retrys.
let us know how it works out.
-mark
PS: I was looking at the source for glibc 2.1.2, but it appears to
be pretty static.
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
