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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
