[389-users] ldap browser hangs entire server

[Rich Megginson]

On 03/28/2011 12:51 PM, Quint Van Deman wrote:
> Hello--
>
> I'm seeing some odd behaviour in a 389ds installation, and I'd like to
> know if others have as well.
> Here's what I know:
> 1. The server is configured never to drop connections due to idle
> timeout (set to 0 in console)
> 2. The server is under very light load (development)
> 3. Once in a while, one of the connections will close with an error
> code of T2 (e.g. [25/Mar/2011:11:07:32 -0400] conn=19 op=-1 fd=67
> closed - T2)
> 4. After a single T2 occurs, all future attempts to the directory are
> unsuccessful.  The process is still running, but completely
> unresponsive.
> 5. If I dig into the logs a bit further I discover that connection 19
> was a software developer using a windows based ldap browser.
> 6. I also notice that while most other connections follow a logical
> order of BIND, SRCH, RESULT, UNBIND, this particular connection does a
> BIND&  leaves it open.
> 7. I also notice that the despite the idle timeout setting above, the
> last RESULT from this connection comes exactly an hour before the T2.
> [25/Mar/2011:10:07:26 -0400] conn=19 op=48 SRCH
> base="cn=XXXX,ou=PeopleTest,dc=dev,dc=XXX,dc=edu" scope=0
> filter="(objectClass=*)" attrs="* createTimestamp creatorsName
> entryflags federationboundary localentryid modifiersName
> modifyTimestamp structuralObjectClass subordinatecount
> subschemaSubentry aci"
> [25/Mar/2011:10:07:26 -0400] conn=19 op=48 RESULT err=0 tag=101
> nentries=1 etime=0 notes=U,P
> [25/Mar/2011:10:07:31 -0400] conn=19 op=50 SRCH
> base="cn=XXXX,ou=PeopleTest,dc=dev,dc=XXX,dc=edu" scope=0
> filter="(objectClass=*)" attrs="* createTimestamp creatorsName
> entryflags federationboundary localentryid modifiersName
> modifyTimestamp structuralObjectClass subordinatecount
> subschemaSubentry aci"
> [25/Mar/2011:10:07:31 -0400] conn=19 op=50 RESULT err=0 tag=101
> nentries=1 etime=0 notes=U,P
> [25/Mar/2011:11:07:32 -0400] conn=19 op=-1 fd=67 closed - T2
>
> I found this bug that seems similar, but I don't see any mention of
> some of the specific criteria that leads my instance to hang:
> https://bugzilla.redhat.com/show_bug.cgi?id=668619
Most any kind of use can trigger this bug.  I suggest upgrading to 
389-ds-base-1.2.8.rc2 from updates-testing or epel-testing and see if 
you can reproduce this problem.
> If anyone has any advice I'd be interested.  In the meantime it looks
> like I'm due to sign up for a bugzilla account.
>
> Thanks,
>
> Quint
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users