Although Quanah hasn't been able to trigger this yet, the regression
test in master he wrote has been consistently able to trigger for me on
my machine, so I've started to investigate.
For posterity and in case anyone is interested, I have uploaded the
testrun/ directory from a failing run (I suspect the fact of this laptop
having a slow 2-core CPU helps) with a slightly patched slapd that
records the thread ID as well since, in part, this seems like a race of
some sort.
The tgz is available at
ftp://ftp.openldap.org/incoming/its8444-regression-testrun-sync,stat.tgz
So far it looks like replica #3's threads 7f50fb7fe700 and 7f51017bb700
are both trying to apply the modification with CSN
20170605125334.856475Z#000000#001#000000 which sends it into a full
refresh.=20
--=20
Ond=C5=99ej Kuzn=C3=ADk
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Full_Name: Gregory Noe
Version: 2.4.44
OS: Debian 8.7
URL: ftp://ftp.openldap.org/incoming/gregory-noe-170605.tar
Submission from: (NULL) (63.142.209.94)
Slapcat is not honoring the '-g' option. The output includes entries from glued
subordinates when it shouldn't. The attached test script
(gregory-noe-170605.tar) sets up the following DIT with inetOrgPerson entries in
each OU:
dn: dc=example,dc=com
|- ou=NonSub00,dc=example,dc=com
|- ou=NonSub01,dc=example,dc=com
|- ou=NonSub02,dc=example,dc=com
glued sub: ou=Accounting,dc=example,dc=com
glued sub: ou=Administrative,dc=example,dc=com
glued sub: ou=Janitorial,dc=example,dc=com
Then the script runs 'slapcat -g -b dc=example,dc=com | grep ^dn'. The result
contains entries from all three glued subordinates.
Tested using Symas OpenLDAP 2.4.44.5
Full_Name: Quanah Gibson-Mount
Version: 2.4.43
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
When using glued/subordinate databases, the "limits" directive needs to be set
on the parent as well as subordinate dbs to be applied if there are global
limits in place. This is currently not documented. Otherwise, the "limits"
directive settings on the subordinate databases is not honored.