Interesting. I can't seem to imagine why this behaved the way it did = (looking over my config again) I am just happy that moving it fixed = the issue.
On Feb 14, 2010, at 00:55 , [email protected] wrote: >> First of all, I am paraphrasing. No one is hiding anything from you = =3D >> Pierre. You need only ask.=3D20 >>=20 >>> It is supposed to be a bug. It's also the reason I asked from the >>> beginning to see the real configuration, real data and real = operation >>> causing the issue. If you keep hiding essential details, and only =3D= >> provide >>> bits of information each time, it'll take ages to just discover = where =3D >> the >>> issue is. >>=20 >>=20 >>> So now the only way to keep this ITS open is to see your ENTIRE =3D >> slapd.conf >>> (except passwords, of course). An even better alternative would be = to >>> receive a sanitized slapd.conf, a LDIF and a search operation based = on >>> ldapsearch that clearly illustrates the issue, like what I posted a = =3D >> couple >>> of postings ago. >>=20 >> Here, the entire sanitized config. I left out the ACL file (the = include =3D >> statement at the very end), but the behavior in question was = happening =3D >> to the rootdn user as well, meaning ACLs weren't the culprit. I also = =3D >> removed 14 of 15 of the syncrepl stanzas for brevity, as they were = all =3D >> the same aside from hostname/IP. >>=20 >> NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote = the =3D >> original (dysfunctional) position vs the current (functional) = position. >=20 > I can't see any difference in behavior with the configuration in > <ftp://ftp.openldap.org/incoming/slapd-its6471-1.conf>, the data and = the > ldapsearch command described in my previous posting (the only = difference > is that now, after "./run -b hdb test003" you need to manually create > directory "testrun/db.2.a" for the log database, and bind as the = rootdn to > perform the search). I tried both HEAD and current re24 code, which > should not differ much from 2.4.21. The only modifications to > configuration are related to: statically built backends/overlays, no = ACLs, > no TLS. Also, valgrind does not show anything strange (like dangling > pointers or so) which could be symptoms of doing nasty things with = memory > that make my setup work "by chance". >=20 > p. >=20
