This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/12350] New: Resolver doesn't save RES_SNGLKUP/RES_SNGLKUPREOP state in getaddrinfo


http://sourceware.org/bugzilla/show_bug.cgi?id=12350

           Summary: Resolver doesn't save RES_SNGLKUP/RES_SNGLKUPREOP
                    state in getaddrinfo
           Product: glibc
           Version: 2.12
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: foom@fuhm.net


If you have a broken nameserver which can't deal with multiple requests sent at
the same time (like I have just now discovered that I do after upgrading glibc:
a broken load balancer actually), then glibc attempts to work around the
problem with the single-lookup and single-lookup-reopen code (thanks!).

Unfortunately, the way the fallback is working, every single time a dns query
is made, it has a 5 second timeout before it tries the fallback single-lookup
mode. It looks like the code is attempting to save the fact that you have a
broken resolver so that only the first name resolution in a process is delayed
by 5 seconds. In resolv/res_send.c:send_dg:
 statp->options |= RES_SNGLKUP;

Unfortunately, that modification of options is defeated by the code in
sysdeps/posix/getaddrinfo.c:gaih_inet that surrounds the (eventual) call to
send_dg:

          old_res_options = _res.options;
          _res.options &= ~RES_USE_INET6;
          [...]
          _res.options = old_res_options;

So, the modification to the resolver parameters only takes effect during a
single call to getaddrinfo. Perhaps the code in gaih_inet should save/restore
only the RES_USE_INET6 flag, and not the entirety of options?

On the other hand, it might not be the best idea to permanently set the
RES_SNGLKUP flag just by ever having lost a single dns packet during the time
an app has been running (when talking to a working nameserver), even if the
code was originally intended to. So maybe it'd be better to simply remove the
modification of statp->options entirely?

Certainly I hope to have my nameserver setup fixed sooner rather than later, so
this bug is more of an "FYI" than something that I'd ever use the fix for.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]