Rich Megginson wrote:
On 02/11/2014 10:32 PM, Timothy Pollard wrote:

After our LDAP instance has been running for a while large LDAP searches in
our userRoot start hanging. This appears to be caused by the entryrdn index
becoming corrupt since it can be fixed by regenerating the entryrdn index.

To give an example of a command that fails:

ldapsearch -x -b "dc=ourorg,dc=com" -h localhost -D "cn=directory manager" -w
removed objectclass=posixAccount > /dev/shm/ldap_search_output

This hangs after reading a large number of entries. The number of entries
change each time, but I believe it may be actually failing on the same specific
entry each time, and just reading them in a different order.

This can be fixed by stopping ns-slapdand
moving /var/lib/dirsrv/slapd-ldap-04/db/userRoot/entryrdn.db4 out of the way
before running `./db2index -n userRoot -t entryrdn`, but it will then reoccur
after a hour or two or so.

Our system:
$ cat /etc/redhat-release 
CentOS release 6.5 (Final)
$ uname -r
$ rpm -q 389-ds
rpm -q 389-ds-base

Are these servers running in VMs?

In case they're helpful I have stack traces from during both failed and
successful searches. I can send them through if they are useful.

Does anyone have any idea what might be causing this, or how we could go about
fixing it? Should we report it as a bug?


You can attach scripts, logs, stack traces, etc. to the ticket.
Can we also have the output from "dbscan -f /var/lib/dirsrv/slapd-ldap-04/db/userRoot/entryrdn.db4"  when the problem occurs?

And, reindexing entryrdn is necessary for the temporary recovery?  For instance, just restarting the server does not help?  I'm wondering whether the dncache in memory is corrupted or the entryrdn index itself is ...


Thank you,

389 users mailing list

389 users mailing list