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!
Here is a related bug report http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=246057;msg=10
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.
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!
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!
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?)
No comment?
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.
This issue is fixed with the packages in the testing queue.
openldap-2.3.30-2.fc6 has been pushed for fc6, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.