Re: Modify destroys entry (w/BerkeleyDB)

[Erik Barker <erik@erik.ca>]

I've found that manually generating an index file using slapindex
generates an index file that is smaller than one generated normally with
ldapadd (importing the entire directory from LDIF). I've imported the
entire directory ldapadd created the index files listed in the
slapd.conf which creates the first file listed below. I then stop the
server, remove the index file and generate the new one using slapindex
producing the second file listed below (tried both slapindex -f
/etc/openldap/slapd.conf & slapindex -b 'myrootdn' -f
/etc/openldap.slapd.conf). I've tested this using both gdbm & Berkeley
DB3 (3.1.17) for the backend which produce the same results.

attr1.dbb        8404992 (ldapadd)
attr1.dbb        8237056 (slapindex)

After I restart slapd and test the directory, the index *seems* to
function properly but the files sizes are different.

I wonder if there are larger problems with the indexing? I'm currently
running slapd without threads on a RH 6.2 server.

Regards,

Erik

On Tue, 2001-08-28 at 13:27, Carl Litt wrote:
> 
> I have started seeing problems with OpenLDAP 2.0.11 with BerkeleyDB
> 3.1.17.  I'll let the logs tell the story:
> 
> Aug 27 10:45:54 ldap1 slapd[21175]: conn=644228 op=7 MOD dn="mailLocalAddress=ljmyerscough@odyssey.on.ca,ou=passwd,o=Top"
> Aug 27 10:45:55 ldap1 slapd[21175]: ldbm: ==> put: attempt to modify a read-only tree
> Aug 27 10:45:55 ldap1 last message repeated 13 times
> Aug 27 10:45:55 ldap1 slapd[21175]: idl_insert_key: idl_store returned -13
> Aug 27 10:45:55 ldap1 slapd[21175]: ldbm: ==> put: attempt to modify a read-only tree
> [The last 2 lines repeat about 10 times]
> Aug 27 10:45:55 ldap1 slapd[21175]: conn=644228 op=7 RESULT tag=103 err=0 text=
> 
> After this, the entry can no longer be searched from o=Top.  It can
> however be retrieved directly with a base scope.  It sounds like the
> indexes are being corrupted?  When I regenerate the indices with
> slapindex, the entry returns back to normal.
> 
> This is on a relatively stock Redhat 6.2 system with stock Berkeley DB
> distribution (db3-3.1.17-4.6x.i386.rpm) and Rawhide's
> openldap-2.0.11-1.src.rpm using the following ./configure options:
> 
> --with-ldbm-api=berkeley --with-slapd --without-slurpd --without-ldapd
> --with-threads
> 
> I also had to make some changes to the spec, configure, and
> build/openldap.m4 files in order to link with -ldb-3.1 instead of
> -ldb3
> 
> This is all the debug info I have available.  The only times I have seen
> this are after long process runtimes, but I don't know if that's related
> other than by probabilities of failure.
> 
> I am guessing there are still issues with threading and/or BerkeleyDB,
> so I recompiled --without-threads.  But it would be nice to get the
> threading back for SMP.
> 
> Thanks,
> Carl Litt
> Network Administrator
> Execulink Internet
> 
>