ldap browser hangs entire server

[Quint Van Deman]

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

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

[Quint Van Deman]

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(a)redhat.com&gt; 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 www.emergent360.com

[Rich Megginson]

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]

Thanks Rich, I'll give rc2 a try.

-Quint

On Mon, Mar 28, 2011 at 4:42 PM, Rich Megginson <rmeggins(a)redhat.com&gt; 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&lt;rmeggins(a)redhat.com&gt;
> >  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 www.emergent360.com

[Karoly Czovek]

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: [phone] - ext.6710
mobile: [phone]
skype: mo_karoly.czovek
email: karoly.czovek(a)moveoneinc.com
web: http://www.moveoneinc.com

[Rich Megginson]

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.
> >