(ITS#6334) hang during ldapmodify

[mkd@cs.brown.edu]

Full_Name: Mark Dieterich
Version: 2.4.19
OS: debian linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.148.33.203)


Hi all,

I'm not sure if this is a bug or we are doing something wrong.  For
quite some time now, we have been using ldap to provide group
information for our linux/unix desktop machines.  I believer there are
multiple methods of providing group access, this is the format we are using:

# foobar, group, cs.brown.edu
dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu
objectClass: posixGroup
objectClass: top
cn: ugrad
gidNumber: 1200
memberUid: t1
memberUid: t2
memberUid: t3
memberUid: t4
memberUid: t5
.
.
.

Up until recently, this had been working great.  We are now experiencing
hangs whenever we try to update the records with one particular group.
I think the hangs are occur when we try to feed too much data to
ldapmodify at a time.  For instance, if I have the above group and try
to apply the following ldif file:

dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu
changetype: modify
replace: memberUid
memberUid: t1
memberUid: t2
memberUid: t3
memberUid: t4
memberUid: t5
memberUid: t6
memberUid: t7
memberUid: t8
memberUid: t9
.
.
.
memberUid: t2477
memberUid: t2478
memberUid: t2479

The update simply hangs.  Tossing a "-d 65535" shows that the process is
sitting in loop spitting out messages similar to:

ldap_int_select
ldap_result ld 0x1e72bf0 msgid 5
wait4msg ld 0x1e72bf0 msgid 5 (timeout 100000 usec)
wait4msg continue ld 0x1e72bf0 msgid 5 all 1
** ld 0x1e72bf0 Connections:
* host: ldapmaster.cs.brown.edu port: 6360 (default)
refcnt: 2 status: Connected
last used: Thu Oct 15 10:27:45 2009
** ld 0x1e72bf0 Outstanding Requests:
* msgid 5, origid 5, status InProgress
outstanding referrals 0, parent count 0
ld 0x1e72bf0 request count 1 (abandoned 0)
** ld 0x1e72bf0 Response Queue:
Empty
ld 0x1e72bf0 response count 0
ldap_chkResponseList ld 0x1e72bf0 msgid 5 all 1
ldap_chkResponseList returns ld 0x1e72bf0 NULL
ldap_int_select

Hopefully, this means something more to someone on this list than it
does to me;)  Interestingly, if I drop the last entry and change the
ldif file to be:

dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu
changetype: modify
replace: memberUid
memberUid: t1
memberUid: t2
memberUid: t3
memberUid: t4
memberUid: t5
memberUid: t6
memberUid: t7
memberUid: t8
memberUid: t9
.
.
.
memberUid: t2476
memberUid: t2477
memberUid: t2478

Then the update proceeds.  However, if I change the last entry to read:

memberUid: t2478000

Then it hangs again.  Whereas with the last entry of

memberUid: t247800

it updates just fine.  This smells of some buffer filling or something
else similar.  While we originally discovered this using debian's packaged
version of openldap, I confirmed yesterday that the problem still exists in the
most recent stable release (2.4.19).  Other details which may be pertinent:

- we are running back_bdb
- syncprov
- GSSAPI authentication

I'm happy to provide any additional details or debugging information, just let
me know what you need.

Thanks!

Mark