Am Mon, 30 Jan 2012 13:25:16 +0100 schrieb Karsten Heymann karsten.heymann@googlemail.com:

Hi,

I've started playing around with slapd (2.4.23-7.2 from debian squeeze) again and stumbled across a very strange phenomenon: When searching the whole tree for an entry it is found immediately:

0|kheymann@ds1-01:~$ ldapsearch -x -h localhost -b o=mycompany uid=aaa uid # extended LDIF # # LDAPv3 # base <o=mycompany> with scope subtree # filter: uid=aaa # requesting: uid # # aaa, 2, customers, marketing, mycompany dn: uid=aaa,contractID=2,ou=customers,ou=marketing,o=mycompany uid: aaa # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

But when searching any of the intermediate subtrees, no result is returned after a short delay:

0|kheymann@ds1-01:~$ ldapsearch -x -h localhost -b ou=marketing,o=mycompany uid=aaa uid # extended LDIF # # LDAPv3 # base <ou=tc,o=mycompany> with scope subtree # filter: uid=aaa # requesting: uid # # search result search: 2 result: 0 Success # numResponses: 1

The uid attribute is indexed with

0|root@ds1-01:/etc/ldap/slapd.d/cn=config# grep -e ' uid ' *ldif olcDatabase={1}hdb.ldif:olcDbIndex: uid eq

and slapindex generated the index without any error messages. This also seems to happen only with entries created while the slapd is running while the entries from the initial import do not whoe this.

This seems very weird to me. Any hints what could cause this behaviour and what could possibly fix it?

Consider yout search base. The searched object is in subtree ou=marketing dn: uid=aaa,contractID=2,ou=customers,ou=marketing,o=mycompany uid: aaa

while you are search below ou=tc,o=mycompany

-Dieter

Hi,

I'd like to investigate into this further.

2012/1/30 Karsten Heymann karsten.heymann@googlemail.com:

I've started playing around with slapd (2.4.23-7.2 from debian squeeze) again and stumbled across a very strange phenomenon: When searching the whole tree for an entry it is found immediately:

[...]

But when searching any of the intermediate subtrees, no result is returned after a short delay:

[...]

To reduce the number of debugging roundtrips: What would be a recommended loglevel to generate logs for the list with optimal signal/noise ratio for this problems?

Yours Karsten