[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5363) ldapsearch hangs when using ldap for host in nsswitch



rra@stanford.edu wrote:
> rra@stanford.edu writes:
>> ldapsearch calls getaddrinfo inside a mutex because on many systems it's
>> not thread-safe.  However, this means that if libnss-ldap is in use and
>> pointing to LDAP for host information, we get deadlock.  ldapsearch
>> calls getaddrinfo(), which calls into libnss-ldap, which tries to open a
>> connection, which then hits the same lock inside the LDAP libraries.

> Oh, and incidentally, if you're wondering why ldapsearch is using
> libldap_r and hence getting this mutex at all, it's because of the issue
> that I raised on openldap-technical (which I can also file an ITS about if
> it would be appropriate).  We can't ship both libldap and libldap_r and
> have some applications linked against one and some against the other
> because they expose the same symbols and it's caused problems in the past.

> Right now, pending advice, we're taking the easiest possible solution and
> just linking everything against libldap_r.

libldap_r was written solely for use by slapd and slurpd. Anybody else who 
uses it does so at their own risk. Applications are supposed to link with 
libldap. This has been stated several times before.

Until somebody decides to invest some energy into writing a new C API spec, 
(simply dusting off the expired C API draft won't cut it) there is not and 
will never be any official support for threading/re-entrancy in the LDAP API.

> But this particular problem probably wouldn't happen without that.  So one
> solution may be to fix *that* problem, and any advice there is most
> definitely welcome.  (However, I would expect any slapd backend that
> itself did a search to possibly have this same issue, so fixing ldapsearch
> may not fix the full problem.)

Unfortunately your problems with libnss-ldap are outside our purview, and any 
ITS relating to it will just be closed/rejected. The fact that nss-ldap is 
essentially broken is not for us to fix. The problems you encounter from 
breaking our Makefiles in response to the nss-ldap problems are also obviously 
not for us to fix; you did that to yourself.

Unofficially, I would suggest that you look into nss-ldapd. I haven't used it 
personally, and have no idea what's missing in the current implementation. But 
it at least has a fighting chance of working sanely.

The other obvious step in this situation is never to use LDAP for hostname 
resolution. ("Doctor, it hurts when I do this." - "Don't do that.") LDAP is a 
much heavier weight protocol than DNS; as such it's simply the wrong tool for 
the job. (Note - I like using DNS servers backed by LDAP, but that's a 
completely different situation.)
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/