Re: Lockup when moding one particular entry

[David Engeset <davidke@whidbey.net>]

Quanah Gibson-Mount wrote:

> --On Tuesday, October 11, 2005 10:06 AM -0700 David Engeset 
> <davidke@whidbey.net> wrote:
>
>
> > > Are you using back-bdb, back-hdb? What version of the BDB software
> > > are you running? I will also note that 2.2.26 is fairly old at this
> > > point. Do you have a DB_CONFIG file? How many members does the group
> > > you are modding have?
> > >
> > > --Quanah
> > >
> > > --
> > > Quanah Gibson-Mount
> > > Principal Software Developer
> > > ITSS/Shared Services
> > > Stanford University
> > > GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
> > >
> > > "These censorship operations against schools and libraries are stronger
> > > than ever in the present religio-political climate. They often focus on
> > > fantasy and sf books, which foster that deadly enemy to bigotry and 
> > > blind
> > > faith, the imagination." -- Ursula K. Le Guin
> > Quanah,
> > I am using back-bdb, version 4.3.28. Yes I am using a DB_CONFIG file
> > which has the following contents:
>
>
>
> I'll note that BDB 4.3 has been the cause of some issues for people. 
> Also BDB 4.3.29 is the current 4.3 release. BDB 4.2.52 + patches 
> remains the recommended BDB version to use with OpenLDAP.
>
> > set_cachesize 0 134217728 1
> > set_lg_dir /var/log/bdb
> > set_tmp_dir /var/log/bdb
> > set_lg_regionmax 262144
> > set_lg_max 104857600
> > set_lg_bsize 2097152
>
>
>
> > The group that I am editing has 20 members.
>
>
>
>
> The DB_CONFIG file looks alright. I don't see anything jumping out at 
> me as very problematic. Have you investigated upgrading (OpenLDAP & 
> BDB) to see if that will resolve your problems? 2.2.29 is the current 
> 2.2 release, and 2.3 is really more stable than 2.2 in its way (2.3.10).
>
>
> --Quanah
>
>
> --
> Quanah Gibson-Mount
> Principal Software Developer
> ITSS/Shared Services
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
>
> "These censorship operations against schools and libraries are stronger
> than ever in the present religio-political climate. They often focus on
> fantasy and sf books, which foster that deadly enemy to bigotry and blind
> faith, the imagination." -- Ursula K. Le Guin
I have followed your suggestions and used the latest stable version of 
OpenLDAP 2.3.11 and BDB 4.2.52 w/patches. I then tried various 
combinations of the latest Berkeley DB and OpenLDAP. In all cases, the 
problem persists. After hours of debugging I was able to isolate the 
issue to a reproducable event with a very small database and even 
determined the line of code that is hanging. The error seems to ocurr in 
BDB but I was unable to trace it further after several attempts. While 
it appears to be hanging on a lock, I am unable to determine what data
is being locked but never unlocked.

I have put up on my website the slapd.conf and the two ldifs for each 
database that I used for anyone who wants to independently verify this 
problem.
http://ww2.whidbey.net/davidke/openldap.html
The file and line of code that it will hang on is:
file: servers/slapd/back-bdb/cache.c
function: bdb_cache_entry_db_relock
line: 100, line shown below
rc = env->lock_vec(env, locker, tryOnly ? DB_LOCK_NOWAIT : 0, list, 2,
NULL );

Here is a summary of the problem:

I have two separate databases. The first one has a suffix of 
ou=disconnected,dc=example,dc=com and the second has a suffix of 
dc=example,dc=com.

When I perform an add/modify/delete to the disconnected database 
(ou=disconnected,dc=example,dc=com) and then try to edit a group that is 
given explicit permissions to access that disconnected database, the 
system hangs.

For example, let's say I add an entry to or remove an entry from the 
disconnected database. Then I want to add, modify or delete a member of 
the techgroup group. When I try to do that, the system hangs. Below are 
two access lists that I have tried in slapd.conf to permit full access 
by members of the techgroup:

"access to dn.subtree="ou=disconnected,dc=example,dc=com"
by self write
by dn="cn=Admin,dc=whidbey,dc=net" write
by group="cn=techgroup,ou=structures,dc=example,dc=com" write
by * read"

and

"access to *
by self write
by dn="cn=Admin,dc=example,dc=com" write
by group="cn=techgroup,ou=structures,dc=example,dc=com" write
by * read"

Either of these result in the same problem. It doesn't matter if it has 
read or write access the process will hang on the edit to the techgroup. 
If I were to make a change to the disconnected database and then stop 
slapd and restart it and make a change to the techgroup there is no
problem.

Thank you,
--

David
Whidbey Telecom Internet and Broadband
System Programmer/Sys Admin