[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#1650) -- reproducible index corruption 2.0.23 db3
Well, it's official. I can reproduce the index corruption problems I
have seen using
a simple Net::LDAP script. I am working from a small directory (fewer
than 5000
entries) and using the following script I add the posixAccount
objectClass to a set
of entries (specified by the filter in the 3 argument). I am using a
stock rh7.2 for my
tests which uses db3 version 3.2.9. I am running OpenLDAP 2.0.23.
use Net::LDAP;
my $ldap = Net::LDAP->new('localhost');
my $res = $ldap->bind($ARGV[0],password=>$ARGV[1]);
$res->code && die $res->error;
$res = $ldap->search(filter=>$ARGV[2],['uid']);
$res->code && die $res->error;
my $e;
my $n = 0;
while ($e = $res->pop_entry())
{
my @oc = $e->get_value('objectClass');
next unless grep /eduPerson/is,@oc;
next if grep /posixAccount/is,@oc;
my $uid = $e->get_value('uid');
# Set random values for uidNumber and gidNumber
$e->replace(uidNumber=>int rand 65535);
$e->replace(gidNumber=>int rand 65535);
# Set faked home directory and shell, just to make the entry complete
$e->replace(homeDirectory=>"/home/$uid");
$e->replace(mail=>"$uid\@su.se");
$e->replace(loginShell=>'/bin/false');
push(@oc,'posixAccount');
$e->replace(objectClass=>\@oc);
my $res = $e->update($ldap);
$res->code && die $res->error;
$n++;
}
print STDERR "Modified $n entries\n";
Before each test I reloaded the directory. Each test consists of running
5 parallell
instances of the test script against the directory server. During the
test process I
run the following commands at intervals:
ldapsearch -x -h localhost 'objectClass=eduPerson' uid | grep dn: | wc -l
Since I am not modifiying adding or removing the eduPerson objectClass
value this
command should always return the same number of entries. Note that the
script modifies
subsets of the <em>entries</em> which are of eduPerson objectClass.
After a while
(I believe it may be related to each parallell instance of the script
finishing) the eduPerson
count begins to fluctuate. After the tests finish I can "fix" the
problem by running slapindex.
This is what a test-run looks like:
[leifj@klapautius leifj]$ ldapsearch -x -h localhost
'objectClass=eduPerson' uid | grep dn: | wc -l
4618
[leifj@klapautius leifj]$ ldapsearch -x -h localhost
'objectClass=eduPerson' uid | grep dn: | wc -l
4618
[leifj@klapautius leifj]$ ldapsearch -x -h localhost
'objectClass=eduPerson' uid | grep dn: | wc -l
4618
[leifj@klapautius leifj]$ ldapsearch -x -h localhost
'objectClass=eduPerson' uid | grep dn: | wc -l
4097
[leifj@klapautius leifj]$ ldapsearch -x -h localhost
'objectClass=eduPerson' uid | grep dn: | wc -l
4100
[leifj@klapautius leifj]$ Modified 26 entries
Modified 46 entries
Modified 79 entries
[leifj@klapautius leifj]$ ldapsearch -x -h localhost
'objectClass=eduPerson' uid | grep dn: | wc -l
4111
Next I will try this with different databases. I don't believe the
database has anything
to do with it though. I will also try this with REL_ENG_2 If you guys
think it might be interesting.
I will try to find another os to try (to elliminate thread-related
problems). Any other thoughts?
Cheers Leif