Your message dated Mon, 2 Mar 2009 04:32:31 -0800
with message-id <[email protected]>
and subject line Re: Bug#359713: libldap2: libldap should not use locks around
threadsafe functions (deadlock in hostname lookups)
has caused the Debian Bug report #359713,
regarding libldap2: libldap should not use locks around threadsafe functions
(deadlock in hostname lookups)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
359713: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359713
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Subject: libldap2: libldap should not use locks around threadsafe functions
(deadlock in hostname lookups)
Package: libldap2
Version: 2.1.30-13
Severity: important
There are issues with using an LDAP server with hostname lookups (having
hosts: files ldap dns in /etc/nsswitch.conf). (see #218958, #340601 and
#343151) Recently we have been bit by this because udev does name
lookups at boot time causing all sorts of problems (somehow this also
triggers this problem).
The problem seems to be caused by some locks that are acquired when
doing hostname lookups. For a hostname lookup, the name of the ldap
server as defined in ldap.conf (or /etc/libnss-ldap.conf) is also looked
up (even if it is an ip address) but hangs because another hostname
lookup is already taking place. This causes a deadlock. It could also be
caused by a reverse lookup done in ldap_host_connected_to() when the
connection is established. (I already spent too much time at looking at
the code now)
I have tried to look into libraries/libldap/{os-ip.c,util-int.c} (where
hostname lookups are done) to see if getting rid of the locks around
getnameinfo(3) and getaddrinfo(3) solves anything (both should be
threadsafe anyway according to POSIX) but I've not been successful. (my
unsuccessful patch is attached)
Maybe another approach would be to detect in libraries/libldap/*.c if an
ip address was used as host and not use getaddrinfo() to get the ai_addr
field.
Anyway these hostname lookups are causing serious problems for us. I've
also had a look into openldap 2.2.26 sources but they seem similar.
A solution is to add the names of all the ldap servers from ldap.conf
to /etc/hosts but this doesn't seem to work for the udev problem.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing'), (50, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.12-west-optiplex
Locale: LANG=C, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Versions of packages libldap2 depends on:
ii libc6 2.3.5-13 GNU C Library: Shared libraries an
ii libgnutls12 1.2.9-2 the GNU TLS library - runtime libr
ii libsasl2 2.1.19-1.9 Authentication abstraction library
libldap2 recommends no packages.
-- no debconf information
--
-- arthur de jong - [email protected] - west consulting b.v. --
--- os-ip.c.orig 2006-03-28 12:50:19.000000000 +0200
+++ os-ip.c 2006-03-28 12:51:21.000000000 +0200
@@ -369,13 +369,17 @@
#ifdef LDAP_R_COMPILE
/* most getaddrinfo(3) use non-threadsafe resolver libraries */
+ /* OUR getaddrinfo(3) is threadsafe !!!
ldap_pvt_thread_mutex_lock(&ldap_int_resolv_mutex);
+ */
#endif
err = getaddrinfo( host, serv, &hints, &res );
#ifdef LDAP_R_COMPILE
+ /* OUR getaddrinfo(3) is threadsafe !!!
ldap_pvt_thread_mutex_unlock(&ldap_int_resolv_mutex);
+ */
#endif
if ( err != 0 ) {
--- util-int.c.orig 2006-03-28 13:11:52.000000000 +0200
+++ util-int.c 2006-03-28 13:15:18.000000000 +0200
@@ -215,11 +215,15 @@
#if defined( HAVE_GETNAMEINFO )
#if defined( LDAP_R_COMPILE )
+ /* OUR getnameinfo(3) is threadsafe !!!
ldap_pvt_thread_mutex_lock( &ldap_int_resolv_mutex );
+ */
#endif
rc = getnameinfo( sa, len, name, namelen, NULL, 0, 0 );
#if defined( LDAP_R_COMPILE )
+ /* OUR getnameinfo(3) is threadsafe !!!
ldap_pvt_thread_mutex_unlock( &ldap_int_resolv_mutex );
+ */
#endif
if ( rc ) *err = AC_GAI_STRERROR( rc );
return rc;
--- End Message ---
--- Begin Message ---
On Mon, Mar 02, 2009 at 11:59:55AM +0100, Arthur de Jong wrote:
> On Sun, 2009-03-01 at 20:28 -0800, Steve Langasek wrote:
> > You filed a similar bug report, bug #340601, that turned out to be the
> > same deadlock issue; and that bug was fixed precisely by adding a
> > patch to disable the mutexes around getaddrinfo() and getaddrinfo().
> > Is this other NSS deadlock bug still an issue, or was it resolved by
> > this same patch?
> I think this is now solved but most of our LDAP-releated problems were
> solved when using nss-ldapd instead of nss-ldap so I could be wrong
> here.
> I think this bug was just to summarise what I tried to do to fix this
> problem before deciding to take another approach. I think you should
> close this bug.
Ok, closing.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
[email protected] [email protected]
--- End Message ---
