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
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:
- 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
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:
- 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
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 Megginsonrmeggins@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:
- 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
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 Megginsonrmeggins@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:
- 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
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.
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@lists.fedoraproject.org