Re: slapd stability problems with add/change operations

[Adrian Gschwend <adrian.gschwend@bfh.ch>]

Adrian Gschwend wrote:

> > In any case, it may be worthwhile to build with debugging symbols, and 
> > then when slapd locks up, run gdb on the process and get a back trace 
> > of where all the threads are at.
>
>
> ok, I will try to do that to make sure we can at least locate the 
> problem. I will also try to run the DB on another testserver I have to 
> see if I run into the same problems there. One testbox ist FreeBSD 4.9 
> but beside this the same setup (but different hardware too), the second 
> textbox I've just set up now is Debian 3.1 with OpenLDAP 2.2.23

ok now it's getting extremely weird:

- complete new HW
- debian 3.1
- openldap 2.2.23
- bdb 4.2.52 with latest patches
- slapcat on freebsd, slapadd on debian

Used to work for some hours, and now it locked twice, each time with an 
add operation. We do not have any entries in the log that the cache or 
the locks were on the limit. loglevel is 256

The last thing we will try now is to rebuild the complete DB from 
scratch via the meta database and not via slapcat/slapadd.

Also, I will try to compile it with debug symbols on the BSD box but I 
don't really know a lot about how to back trace the threads and all that 
stuff. Can anyone help me out on that?

cu

Adrian

--
Adrian Gschwend
System Administrator
Berne University of Applied Sciences
Biel, Switzerland