From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9834 invoked by alias); 27 Dec 2010 17:50:11 -0000 Received: (qmail 9825 invoked by uid 22791); 27 Dec 2010 17:50:10 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Dec 2010 17:50:06 +0000 From: "foom at fuhm dot net" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/12350] New: Resolver doesn't save RES_SNGLKUP/RES_SNGLKUPREOP state in getaddrinfo X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: foom at fuhm dot net X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 27 Dec 2010 21:31:00 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00056.txt.bz2 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.