+++ This bug was initially created as a clone of Bug #211045 +++

Description of problem:
An ldap server has been installed and configured for hosting the user/password
database. Accessing through nss_ldap and ldapi:/// (e.g. over a socket) works
fine and gives very good performance. Turning on nscd generates timeouts of
5-10sec for each call. Turning of nscd bring is back to immediate response

Version-Release number of selected component (if applicable):
2.5-2

How reproducible:
always

Steps to Reproduce:
1.Setup ldap with ldapi:///
2.Point nss_ldap to ldapi
3.Turn on nscd
4.time id something
  
Actual results:
# time id something
id: something: No such user

real    0m5.023s
user    0m0.008s
sys     0m0.008s


Expected results (e.g. w/o nscd):
# time id something
id: something: No such user

real    0m0.025s
user    0m0.004s
sys     0m0.016s


Additional info:
o Looks like it happens in FC5, too
o The logs say

Oct 17 00:05:14 fifty nscd: nss_ldap: reconnecting to LDAP server (sleeping 4
seconds)...
Oct 17 00:05:18 fifty nscd: nss_ldap: failed to bind to LDAP server
ldapi://%2fvar%2frun%2fldapi/: Can't contact LDAP server
Oct 17 00:05:18 fifty nscd: nss_ldap: reconnecting to LDAP server (sleeping 8
seconds)...
Oct 17 00:05:26 fifty nscd: nss_ldap: failed to bind to LDAP server
ldapi://%2fvar%2frun%2fldapi/: Can't contact LDAP server
Oct 17 00:05:26 fifty nscd: nss_ldap: reconnecting to LDAP server (sleeping 16
seconds)...
Oct 17 00:05:42 fifty nscd: nss_ldap: failed to bind to LDAP server
ldapi://%2fvar%2frun%2fldapi/: Can't contact LDAP server
Oct 17 00:05:42 fifty nscd: nss_ldap: reconnecting to LDAP server (sleeping 32
seconds)...
Oct 17 00:06:14 fifty nscd: nss_ldap: failed to bind to LDAP server
ldapi://%2fvar%2frun%2fldapi/: Can't contact LDAP server
Oct 17 00:06:14 fifty nscd: nss_ldap: reconnecting to LDAP server (sleeping 64
seconds)...

But still there are accesses through nss_ldap over ldapi in between. So while
there is a log that seems to timeout the connection does happen after a while
and returns the correct result.

o I've googled on nscd and ldapi and some with a similar issue seem to blame too
  many open fds. But that doesn't seem to make much sense.

Is there anything else I can offer for helping to debug this? Thanks!

-- Additional comment from Axel.Thimm on 2006-10-16 18:13 EST --
Here is a related bug report

http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=246057;msg=10

-- Additional comment from drepper on 2006-10-16 19:04 EST --
The nscd daemon probably does not have the permissions to talk to the ldap
daemon.  nscd uses the NSS module just like any other program.  Any difference
is an artifact of the way nscd is running.  You likely have to adjust the
permissions somehow somewhere.

-- Additional comment from Axel.Thimm on 2006-10-17 04:13 EST --
Thanks Ulrich, that was it.

For posterity: the default owner/mode of the socket are root:root 0755. Making
that root:nscd 0775 fixed it.

I don't see a way to specify ownership/mode in openldap anywhere. Maybe one
could arrange the openldap package to offer that socket with proper permissions
in advance, but I'm not sure it's worth the trouble. Closing as NOTABUG, but
feel free to move to openldap if you think it's worth hunting further. Thanks again!


-- Additional comment from Axel.Thimm on 2006-10-17 10:33 EST --
Unfortunately there is still an issue with ldapi and nscd: (re)starting slapd
removes the permissions and breaks nscd again. I'm reopening against openldap:

# ls -ld /var/run/ldapi; /etc/init.d/ldap restart; ls -ld /var/run/ldapi
srwxrwxr-x 1 root nscd 0 Oct 17 10:04 /var/run/ldapi
Stopping slapd:                                            [  OK  ]
Stopping slurpd:                                           [  OK  ]
Checking configuration files for slapd:  config file testing succeeded
                                                           [  OK  ]
Starting slapd:                                            [  OK  ]
Starting slurpd:                                           [  OK  ]
srwxr-xr-x 1 root root 0 Oct 17 16:22 /var/run/ldapi

Perhaps the init file should change

        if test x$SLAPD_LDAPI = xyes ; then
            harg="$harg ldapi:///"
        fi

to

        if test x$SLAPD_LDAPI = xyes ; then
            harg="$harg ldapi:///???x-mod=777"
        fi

Or perhaps modify group ownership/permission after starting slapd in the init
script. Thanks!

-- Additional comment from Axel.Thimm on 2006-10-17 14:04 EST --
The x-mod syntax does not work anymore, the ldap developers deactivated this in
this commit

http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/daemon.c.diff?r1=1.257&r2=1.258

The remaining options are to adjust permissions manually after starting slapd,
using umask 0, or patching the source (e.g. to always create the socket as 0777).

I'd go for the last option, because the manual chgrp/chmod only works for
hardwired socket file names and umask 0 may affect other files (replicas?)


-- Additional comment from Axel.Thimm on 2006-11-24 21:16 EST --
No comment?

-- Additional comment from Axel.Thimm on 2007-02-07 04:06 EST --
Fixed upstream in 2.3.29. Please upgrade FC6's package or use the patch at

ftp://ftp.openldap.org/incoming/ivan-nejgebauer-061012.patch

It is against 2.3.27, e.g. the version used in FC6, so it should apply cleanly.
It actually performs what had been suggested in comment #5.

-- Additional comment from Axel.Thimm on 2007-02-16 05:49 EST --
This issue is fixed with the packages in the testing queue.