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

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

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

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Thanks Rich--

Is the release candidate stable enough fro production use at this point?


On Mon, Mar 28, 2011 at 3:02 PM, Rich Megginson <rmeggins@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@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@emergent360.com
Visit us at www.emergent360.com
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

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

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Thanks Rich, I'll give rc2 a try.

-Quint

On Mon, Mar 28, 2011 at 4:42 PM, Rich Megginson <rmeggins@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@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@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@emergent360.com
Visit us at www.emergent360.com
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Will the update affect my own objectclasses?
Can I copy somehow my own schemas to the new salve servers?


On Mar 28, 2011, at 10:54 PM, Quint Van Deman wrote:

>
>
> Thanks Rich, I'll give rc2 a try.
>

--
Karoly CZOVEK
Global Systems Administrator
MoveOne IT Department

Eastern Europe - Balkans - CIS& Central Asia - Middle East& Africa -
Asia Pacific
phone: +36 1 266 0181 - ext.6710
mobile: +36 70 708 9953
skype: mo_karoly.czovek
email: karoly.czovek@moveoneinc.com
web: http://www.moveoneinc.com



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

On 03/28/2011 03:14 PM, Karoly Czovek wrote:
> Will the update affect my own objectclasses?
If you yum update from 1.2.7.5 to 1.2.8.rc2 it should not affect any of
your data or configuration.
> Can I copy somehow my own schemas to the new salve servers?
Yes. If you have user defined schema files that you want to copy to
another server, you can just scp them

cd /etc/dirsrv/slapd-masterinstance/schema
scp file1.ldif file2.ldif ....
root@otherserver:/etc/dirsrv/slapd-slaveinstance/schema

you will have to restart the slave in order for the new schema to take
effect
>
> On Mar 28, 2011, at 10:54 PM, Quint Van Deman wrote:
>
>>
>> Thanks Rich, I'll give rc2 a try.
>>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users