HI!
on one platform on various servers I see strange entries in back-monitor (see below). It's an installation of RE24 committ-id 22ee28752e3e0d2a6910a22922fc69befd78578a self-compiled on RHEL 6.2 x86_64 linked to BDB, SASL and OpenSSL shipped with RHEL.
We have two custom overlays in this setup but disabling them did not make this monitor entries disappear.
On my local test system on openSUSE 11.4 x86_64 I don't see this.
Any idea under which condition such monitor entries can appear and where to look in my configuration?
Ciao, Michael.
--------------------------------- snip --------------------------------- dn: cn=Connection 0,cn=Connections,cn=Monitor structuralObjectClass: monitorConnection creatorsName: modifiersName: createTimestamp: 19700101000000Z modifyTimestamp: 19700101000000Z monitorConnectionNumber: 0 monitorConnectionProtocol: 0 monitorConnectionOpsReceived: 0 monitorConnectionOpsExecuting: 0 monitorConnectionOpsPending: 0 monitorConnectionOpsCompleted: 0 monitorConnectionGet: 0 monitorConnectionRead: 0 monitorConnectionWrite: 0 monitorConnectionMask: L monitorConnectionListener: monitorConnectionPeerDomain: unknown monitorConnectionPeerAddress: unknown monitorConnectionLocalAddress: monitorConnectionStartTime: 19700101000000Z monitorConnectionActivityTime: 19700101000000Z entryDN: cn=Connection 0,cn=Connections,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE
dn: cn=Connection 0,cn=Connections,cn=Monitor structuralObjectClass: monitorConnection creatorsName: modifiersName: createTimestamp: 19700101000000Z modifyTimestamp: 19700101000000Z monitorConnectionNumber: 0 monitorConnectionProtocol: 0 monitorConnectionOpsReceived: 0 monitorConnectionOpsExecuting: 0 monitorConnectionOpsPending: 0 monitorConnectionOpsCompleted: 0 monitorConnectionGet: 0 monitorConnectionRead: 0 monitorConnectionWrite: 0 monitorConnectionMask: L monitorConnectionListener: monitorConnectionPeerDomain: unknown monitorConnectionPeerAddress: unknown monitorConnectionLocalAddress: monitorConnectionStartTime: 19700101000000Z monitorConnectionActivityTime: 19700101000000Z entryDN: cn=Connection 0,cn=Connections,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE
--On Wednesday, February 01, 2012 5:45 PM +0100 Michael Ströder michael@stroeder.com wrote:
HI!
on one platform on various servers I see strange entries in back-monitor (see below). It's an installation of RE24 committ-id 22ee28752e3e0d2a6910a22922fc69befd78578a self-compiled on RHEL 6.2 x86_64 linked to BDB, SASL and OpenSSL shipped with RHEL.
We have two custom overlays in this setup but disabling them did not make this monitor entries disappear.
On my local test system on openSUSE 11.4 x86_64 I don't see this.
Any idea under which condition such monitor entries can appear and where to look in my configuration?
IIRC, Connection "0" is a special internal slapd connection, but I don't recall for what. ;) If it is showing up twice for search results, then that would be a bug, but I can't quite tell what exactly it is you're reporting.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Wednesday, February 01, 2012 5:45 PM +0100 Michael Ströder michael@stroeder.com wrote:
on one platform on various servers I see strange entries in back-monitor (see below). It's an installation of RE24 committ-id 22ee28752e3e0d2a6910a22922fc69befd78578a self-compiled on RHEL 6.2 x86_64 linked to BDB, SASL and OpenSSL shipped with RHEL.
We have two custom overlays in this setup but disabling them did not make this monitor entries disappear.
On my local test system on openSUSE 11.4 x86_64 I don't see this.
Any idea under which condition such monitor entries can appear and where to look in my configuration?
IIRC, Connection "0" is a special internal slapd connection, but I don't recall for what. ;)
While searching for other problems these entries caught my attention. And I'm wondering why I see this only on a certain OS platform. So knowing what it's for would be good to narrow down the cause.
If it is showing up twice for search results, then that would be a bug, but I can't quite tell what exactly it is you're reporting.
Yes, returning two entries with the same DN violates the data model. That's the issue. Or maybe Connection 0 should never appear at all?
But before writing an ITS I'd like to narrow down things to be able to reproduce the issue in a minimal test configuration.
Ciao, Michael.
--On Wednesday, February 01, 2012 7:43 PM +0100 Michael Ströder michael@stroeder.com wrote:
If it is showing up twice for search results, then that would be a bug, but I can't quite tell what exactly it is you're reporting.
Yes, returning two entries with the same DN violates the data model. That's the issue. Or maybe Connection 0 should never appear at all?
But before writing an ITS I'd like to narrow down things to be able to reproduce the issue in a minimal test configuration.
Howard's recollection is they are syncrepl connections (which all non-syncrepl connections start at 1000 on the consumer). So I'd assume these systems are configured as syncrepl consumers. Definitely file an ITS on the result for connection0 showing twice.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Wednesday, February 01, 2012 7:43 PM +0100 Michael Ströder michael@stroeder.com wrote:
If it is showing up twice for search results, then that would be a bug, but I can't quite tell what exactly it is you're reporting.
Yes, returning two entries with the same DN violates the data model. That's the issue. Or maybe Connection 0 should never appear at all?
But before writing an ITS I'd like to narrow down things to be able to reproduce the issue in a minimal test configuration.
Howard's recollection is they are syncrepl connections (which all non-syncrepl connections start at 1000 on the consumer). So I'd assume these systems are configured as syncrepl consumers.
It's a MMR setup with two nodes.
Definitely file an ITS on the result for connection0 showing twice.
http://www.openldap.org/its/index.cgi?findid=7145
Ciao, Michael.
Michael Ströder wrote:
Quanah Gibson-Mount wrote:
--On Wednesday, February 01, 2012 7:43 PM +0100 Michael Ströder michael@stroeder.com wrote:
If it is showing up twice for search results, then that would be a bug, but I can't quite tell what exactly it is you're reporting.
Yes, returning two entries with the same DN violates the data model. That's the issue. Or maybe Connection 0 should never appear at all?
But before writing an ITS I'd like to narrow down things to be able to reproduce the issue in a minimal test configuration.
Howard's recollection is they are syncrepl connections (which all non-syncrepl connections start at 1000 on the consumer). So I'd assume these systems are configured as syncrepl consumers.
It's a MMR setup with two nodes.
Definitely file an ITS on the result for connection0 showing twice.
Ok, I can see single "Connection 0" entry on a consumer in a single-master replication setup.
Now I've tried to come up with a simplified MMR setup to reproduce the monitor entry with DN cn=Connection 0,cn=Connections,cn=Monitor showing up twice. But still on both providers there's a single "Connection 0" entry.
So any more conditions under which such a "Connection 0" is used internally?
Ciao, Michael.
openldap-technical@openldap.org
-
Michael Ströder -
Quanah Gibson-Mount