Bug 553032

I'm having this problem, too.  Because of it, the entire system hangs at startup.  This is a really serious bug.  In the RHEL version (bug #436307), the runuser maintainer has determined that this is not a bug in runuser.

I'm still having this critical problem with nss_ldap-264-8.fc12.x86_64.  Because of this bug, the slapd service cannot be restarted without manually editing nsswitch.conf to have "passwd: files" instead of "passwd: files ldap".  After the service starts, the change must be manually repeated.

Although it might be somewhat uncommon for Fedora users to set up an LDAP server, I'm guessing this will be a huge problem in RHEL 6.

There is a new package named nss-ldapd in F12. This package provides a different implementation of the NSS LDAP functionality that should be more scalable and reliable.

The package will soon be renamed to nss_pam_ldapd (request is pending).

Please give it a try. There is a good chance that it will address the problem you are observing.

Dmitri, thanks for the reference.  I'll look into nss-ldapd when I have a chance.

But I think the bug in nss_ldap should still be fixed anyway (especially since nss_ldap is still the default).

Dmitri, it looks like nss-ldapd has a similar purpose to sssd, but some quick googling didn't shed any light on the matter.  Are these projects competitors?

Well, I suspect it is not going to be a default soon.

Here is the landscape:

* nss_ldap is old and buggy, has some architectural problems
* sssd is the future but for some time it does not have full functionality (support of all maps) to replace nss_ldap completely. We going there but it will take some time. I would say a year may be more may be less. We do not expect everybody to jump on the sssd wagon day one. There might be some other use cases that we currently do not see that willp revent users to take advantage of the sssd. Then they would have to fall back to nss_ldap style functionality 
* nss_ldapd a much better solution as nss_ldap, supports all maps and solves architectural problems. So it is a natural interim step on the path from nss_ldap to sssd.

Hope this helps.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Easiest workaround:

echo "bind_policy soft" >> /etc/ldap.conf

If you have multiple servers listed in uri or host, this may not necessarily do exactly what you want if the first server fails, in that case, look at the nss_reconnect_tries,nss_reconnect_sleeptime,nss_reconnect_maxsleeptiome,nss_reconnect_maxconntries options.

There are valid reasons to switch from nss_ldap, but this isn't one ...

Buchan, nss_ldap really isn't a reasonable alternative for sssd, even with options like "bind_policy soft".  Unfortunately, nss_ldap has no way to communicate between processes, so if a server or network connection goes down, each process has to figure that out individually.  In the end, there's no way to avoid hangs other than using something like sssd.

I was searching the problem and finally i found it in my case. I am going to describe the procedure that I followed.

1. Turn off nscd service and execute the next command
 
 nscd -d

2. In other console try to run next:
 
bash -x /etc/init.d/slapd start

3. Script stopped when try to run "runuser", look the first console and you can see that some group could not be found.

4. Go to the /etc/security/limits.d and search that group and comment that line. In my case was pulse-rt.

5. try again start slapd service.

I hope this information can be usefull. good luck.