Thanks Rich, I'll give rc2 a try. -Quint On Mon, Mar 28, 2011 at 4:42 PM, Rich Megginson <rmeggins@xxxxxxxxxx> wrote: > On 03/28/2011 02:09 PM, Quint Van Deman wrote: >> >> Thanks Rich-- >> >> Is the release candidate stable enough fro production use at this point? > > So far it is more stable than 1.2.7.5 >> >> On Mon, Mar 28, 2011 at 3:02 PM, Rich Megginson<rmeggins@xxxxxxxxxx> >> wrote: >>> >>> 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 >>> >> >> > > -- Quint Van Deman | Director, Open Source Consulting | Emergent, LLC Red Hat Certified Architect, Engineer, and Data Center Specialist 1439 N. Great Neck Rd. | Virginia Beach, VA 23454 757-416-6535(O) | 757-287-1738 (M) | 757-412-1060 (F) qvandeman@xxxxxxxxxxxxxxx Visit us at www.emergent360.com -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
