[Date Prev][Date Next] [Chronological] [Thread] [Top]

hang during ldapmodify?



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.

We are running with debian's lenny version of openldap, version 2.4.11-1
(not sure what's different about the "-1" version).  Other details which
may be pertinent:

- we are running back_bdb
- syncprov
- GSSAPI authentication

I have not tried setting up a test server running 2.4.16/19, but did
spend time looking through the chnage logs and bug system and didn't see
anything that appeared to apply.  However, I certainly could have missed
something.

Any help would be most appreciated, as we currently have one group which
we are no longer able to add any entries to.

Thanks!

Mark