This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Bug in nscd GETHOSTBYNAMEv6?
- From: Mark Bucciarelli <mark at hubcapconsulting dot com>
- To: libc-alpha at sources dot redhat dot com
- Date: Thu, 9 Jan 2003 14:59:41 -0500
- Subject: Bug in nscd GETHOSTBYNAMEv6?
- Organization: Hubcap Consulting
>Submitter-Id:=09net
>Originator:=09Mark Bucciarelli
>Organization: Hubcap Consulting
>Confidential:=09no
>Synopsis:=0920 delay in nscd IPv6 lookup
>Severity:=09serious
>Priority:=09medium
>Category:=09libc
>Class:=09=09sw-bug
>Release:=09libc-2.2.93
>Environment: Dell Inspiron 4100
Host type: i386-redhat-linux-gnu
System: Linux pooh 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i38=
6=20
GNU/Linux
Architecture: i686
Addons: c_stubs glibc-compat linuxthreads
Build CFLAGS: -march=3Di386 -freorder-blocks -DNDEBUG=3D1 -g -O3
Build CC: gcc
Compiler version: 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Kernel headers: 2.4.9-9
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: no
Build profile: yes
Build omitfp: no
Build bounded: no
Build static-nss: no
>Description:
When connecting to an XML RPC server on local host, there is sometimes a
20 second delay. This delay appears to be related to how the IPv6 lookup is
attempted.
Unfortunately, I don't know what causes this delay to start occuring. But
it happened very regularly for me, so hopefully it will occur for you too.
Here's a snippet from the nscd.log:
3035: handle_request: request received (Version =3D 2)
3035: GETHOSTBYNAMEv6 (localhost)
3035: Haven't found "6c6f:6361:6c68:6f73:7400:0:fa98:153e" in hosts cache!
When I watch the log file with tail -f, the call to GETHOSTBYNAMEv6 consumes
the entire 20 seconds. Martin v. Lowis, on the python XML-SIG list suggested
I submit a bug report (this stuff is over my head!). Here's a quote from his
email:
| I'm surprised that it infers "6c6f:6361:6c68:6f73:7400:0:fa98:153e",
| though? Have you configured IPv6 interfaces for your system? Doing
| >>> s=3D"6c6f63616c686f7374000000fa98153e"
| >>> s.decode("hex")
| 'localhost\x00\x00\x00\xfa\x98\x15>'
| reveals that something is seriously broken in namelookup: It somehow
| tries to interpret the byte string "localhost" (plus whatever data it
| then has in memory) as an IPv6 packed binary address?????
>How-To-Repeat:
1. Install Python 2.2 (that's what I'm using, may not be necessary.)
2. turn on nscd logging (edit /etc/ncsd.conf)
- uncomment logfile line
- change debug-level from 0 to 5
3. start this xmlrpc server running:
import SimpleXMLRPCServer
def echo(s):
return s
server =3D SimpleXMLRPCServer.SimpleXMLRPCServer(("localhost", 8000))
server.register_function(echo)
server.serve_forever()
4. and run this client code from the python interpreter:
Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xmlrpclib
>>> server =3D xmlrpclib.Server("http://localhost:8000")
>>> server.echo("test")
>Fix:
I don't how to fix this. However, a work around is to use 127.0.0.1 instead of
localhost in the client code.
--
Mark Bucciarelli
Hubcap Consulting, www.hubcapconsulting.com
70 Baker Road, Shutesbury, MA, 01072
tel: (413) 253-0020, fax: (413) 259-1255