Thanks Rich, I'll give rc2 a try.
-Quint
On Mon, Mar 28, 2011 at 4:42 PM, Rich Megginson <rmeggins(a)redhat.com> 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(a)redhat.com>
> 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(a)lists.fedoraproject.org
>>>
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(a)emergent360.com
Visit us at