(ITS#8102) syncrepl_entry: be_modify failed (16)
by tpretz＠gmail.com
Now running RE24 head (commit 1101d4b7dbdb2453076c1075d1ae2375c36f06f9)
Turned on a bit of logging (sync trace args) and grepped out some
lines of interest.
@(#) $OpenLDAP: slapd 2.4.X (Apr 10 2015 20:07:53) $
... skipping ...
syncrepl_message_to_entry: rid=100 DN:
cn=3,ou=stest,dc=example,dc=com, UUID:
0f89951e-94fe-445b-91f8-9e8589c4d1e3
mdb_modify_internal: 0x00ebd167: cn=2,ou=stest,dc=example,dc=com
mdb_modify_internal: replace AttrComment
mdb_modify_internal: replace entryCSN
mdb_modify_internal: replace modifiersName
mdb_modify_internal: replace modifyTimestamp
syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: rid=100 inserted UUID 0f89951e-94fe-445b-91f8-9e8589c4d1e3
syncrepl_entry: rid=100 be_search (0)
syncrepl_entry: rid=100 cn=3,ou=stest,dc=example,dc=com
mdb_modify: cn=3,ou=stest,dc=example,dc=com
mdb_modify: updated id=00ebd167 dn="cn=2,ou=stest,dc=example,dc=com"
syncrepl_entry: rid=101 be_modify cn=2,ou=stest,dc=example,dc=com (0)
syncrepl_message_to_entry: rid=101 DN:
cn=3,ou=stest,dc=example,dc=com, UUID:
0f89951e-94fe-445b-91f8-9e8589c4d1e3
mdb_modify_internal: 0x00ebd168: cn=3,ou=stest,dc=example,dc=com
mdb_modify_internal: delete AttrComment
mdb_modify_internal: replace entryCSN
mdb_modify_internal: replace modifiersName
mdb_modify_internal: replace modifyTimestamp
syncrepl_entry: rid=101 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: rid=101 inserted UUID 0f89951e-94fe-445b-91f8-9e8589c4d1e3
syncrepl_entry: rid=101 be_search (0)
syncrepl_entry: rid=101 cn=3,ou=stest,dc=example,dc=com
mdb_modify: cn=3,ou=stest,dc=example,dc=com
mdb_modify: updated id=00ebd168 dn="cn=3,ou=stest,dc=example,dc=com"
syncrepl_entry: rid=100 be_modify cn=3,ou=stest,dc=example,dc=com (0)
syncrepl_message_to_entry: rid=100 DN:
cn=4,ou=stest,dc=example,dc=com, UUID:
25f4703a-b73e-4d7c-81b8-9f139e267023
mdb_modify_internal: 0x00ebd168: cn=3,ou=stest,dc=example,dc=com
mdb_modify_internal: delete AttrComment
mdb_modify_internal: 16 modify/delete: AttrComment: no such attribute
mdb_modify: modify failed (16)
null_callback : error code 0x10
syncrepl_entry: rid=101 be_modify cn=3,ou=stest,dc=example,dc=com (16)
syncrepl_entry: rid=101 be_modify failed (16)
Thanks
Tom
7 years, 1 month
Re: (ITS#8101) facsimileTelephoneNumber
by hyc＠symas.com
bernhard.pfeiffer(a)brz.gv.at wrote:
> Full_Name: Bernhard Pfeiffer
> Version: 2.4.40
> OS: SUSE Linux 11
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (85.158.227.32)
>
>
> Hey!
>
> There is a problem in core-Schema with facsimileTelephoneNumber and jpegPhoto.
> It is not possible to modify these attributes, for example:
>
> version: 1
>
> dn: uid=testsimon,ou=people,ou=test,dc=gv,dc=at
> changetype: modify
> delete: facsimileTelephoneNumber
> facsimileTelephoneNumber: +43 123 234 34234123
>
> ldap_modify: Inappropriate matching (18)
> additional info: modify/delete: facsimileTelephoneNumber: no equality
> matching rule
>
>
> It is only possible, to delete it completly or replace it.
>
> Is there any Bugfix in plan?
This is not an OpenLDAP bug. The schema definitions for these attributes come from the LDAP RFCs (4519 in this case). You're welcome to submit a proposed revision to the IETF if you want the specs updated. In the meantime, your best approach is to define your own attributes that specify the matching rules you desire.
Closing this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 1 month
Re: (ITS#8102) syncrepl_entry: be_modify failed (16)
by quanah＠zimbra.com
--On Friday, April 10, 2015 5:12 PM +0000 tpretz(a)gmail.com wrote:
> Full_Name: Tom Pressnell
> Version: 2.4.40
> OS: debian wheezy
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (5.63.147.4)
>
>
> Hi,
>
> In testing i have encountered the following when restoring replication
> from multiple providers.
>
> slapd: slapd starting
> slapd: null_callback : error code 0x10
> slapd: syncrepl_entry: rid=106 be_modify failed (16)AsAslapd: do_syncrepl:
> rid=106 rc 16 retrying (9 retries left)
>
> Running 2.4.40 on debian wheezy amd64.
> This occurs with both the mdb and hdb backends.
>
> While the consumer was offline i removed all values of an indexed
> attribute from hundreds of entries, all providers are synced.
>
> Using standard syncrepl (not delta), issue occurs at process startup
> where the consumer has been offline for a short while, i.e. replaying the
> sessionlog not falling back to present.
>
> Having a read of syncrepl.c it would seem that syncrepl_diff_entry is
> called for a entry received from a provider in a race with the same entry
> from another provider in a different thread.
> Both diff calls result in an attribute delete operation, when be_modify
> is hit for the second time it fails with no such attribute as the first
> thread has already removed it (uses DELETE, not SOFTDEL).
Please test against current RE24, as there have been a number of fixes to
syncrepl. Thanks!
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 1 month
(ITS#8102) syncrepl_entry: be_modify failed (16)
by tpretz＠gmail.com
Full_Name: Tom Pressnell
Version: 2.4.40
OS: debian wheezy
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (5.63.147.4)
Hi,
In testing i have encountered the following when restoring replication from
multiple providers.
slapd: slapd starting
slapd: null_callback : error code 0x10
slapd: syncrepl_entry: rid=106 be_modify failed (16)AsAslapd: do_syncrepl:
rid=106 rc 16 retrying (9 retries left)
Running 2.4.40 on debian wheezy amd64.
This occurs with both the mdb and hdb backends.
While the consumer was offline i removed all values of an indexed attribute from
hundreds of entries, all providers are synced.
Using standard syncrepl (not delta), issue occurs at process startup where the
consumer has been offline for a short while, i.e. replaying the sessionlog not
falling back to present.
Having a read of syncrepl.c it would seem that syncrepl_diff_entry is called for
a entry received from a provider in a race with the same entry from another
provider in a different thread.
Both diff calls result in an attribute delete operation, when be_modify is hit
for the second time it fails with no such attribute as the first thread has
already removed it (uses DELETE, not SOFTDEL).
Thanks
Tom
7 years, 1 month
Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com
hguo(a)suse.com wrote:
> Is your build identical to the 2.4.40 on OBS in terms of patches/source
> code revision?
No. It's RE24 with all changes to be released as 2.4.41.
> What distribution did you use for testing?
openSUSE Tumbleweed x86_64.
Ciao, Michael.
7 years, 1 month
Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com
Is your build identical to the 2.4.40 on OBS in terms of patches/source
code revision?
What distribution did you use for testing?
Kind regards,
Howard
On 10/04/15 15:23, Michael Ströder wrote:
> Michael Ströder wrote:
>> Yes, the duplicate occurence should be fixed. I have to check in my
>> installation if it's still an issue.
>
> Using a local build from RE24 branch I cannot see the duplicate
> occurence of
> cn=Connection 0,cn=Connections,cn=Monitor anymore.
>
> Ciao, Michael.
>
>
7 years, 1 month
Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com
Michael Ströder wrote:
> Yes, the duplicate occurence should be fixed. I have to check in my
> installation if it's still an issue.
Using a local build from RE24 branch I cannot see the duplicate occurence of
cn=Connection 0,cn=Connections,cn=Monitor anymore.
Ciao, Michael.
7 years, 1 month
Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com
Last month when I tried OpenLDAP 2.4.40 using your SLES 12 package, I
was still able to get two Connection0s to show up in one response.
It'll be a great news if that's no longer the case with the next release.
Kind regards,
Howard
On 10/04/15 15:08, Michael Ströder wrote:
> hguo(a)suse.com wrote:
>> According to the issue report, the connection 0's DN appears not only
>> once, but twice, in some circumstances. Duplicated DN should not have
>> appeared in server response.
>>
>> Apart from that, connection 0 does not serve any purpose for LDAP
>> clients, therefore its connection details are not useful.
>
> Yes, the duplicate occurence should be fixed. I have to check in my
> installation if it's still an issue.
>
> But IMO it's not the correct solution to completely mask out
> Connection 0.
>
> Ciao, Michael.
>
>
7 years, 1 month
Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms040201060806000805040605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
hguo(a)suse.com wrote:
> According to the issue report, the connection 0's DN appears not only
> once, but twice, in some circumstances. Duplicated DN should not have
> appeared in server response.
>
> Apart from that, connection 0 does not serve any purpose for LDAP
> clients, therefore its connection details are not useful.
Yes, the duplicate occurence should be fixed. I have to check in my=20
installation if it's still an issue.
But IMO it's not the correct solution to completely mask out Connection 0=
=2E
Ciao, Michael.
--------------ms040201060806000805040605
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe
Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0
ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp
pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9
b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q
zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX
9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/
4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E
BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw
HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG
AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu
Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB
FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC
AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py
TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm
CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz
uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm
z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT
5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp
sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076
khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8
J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX
un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG
9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw
NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG
A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4
uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk
Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK
JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih
34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v
KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj
z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf
BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL
KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w
b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0
byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g
Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj
b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt
MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF
BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns
YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl
cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22
A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm
v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3
6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq
YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw
oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxMDEzMDg1MFowLwYJKoZIhvcNAQkEMSIE
INjY2+k8RYDr+AWl9Tdry/StUnpv0l5mMlEZSSB1gSDBMGwGCSqGSIb3DQEJDzFfMF0wCwYJ
YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB
lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ
EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG
A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh
cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq
hkiG9w0BAQEFAASCAQCjGZUjWWmSZr90Qc5rvU4bxBdLLdl/R61n5bN2grUbuLaMnx4HHyVv
LVPazxss32mJDpPv9Xr1ccusbTHOlLqSXb86g/nV15KcXNuXELqiRTpSXOlyIfU87jKAjdp5
oCZqdQqVZftPUXZyF+qT9OL2kVlXemA8JeBLBuPQXCpOtHyo3TPin+9sCpJJEGwCaJ6qwxaj
ha0C1lKP3gWWr8dN4DQvq7jXatOueIkKxPcxjafbWhBxHeJs1ZrtDu62NqVuLyoSOkT4Jzpm
/hXUFM4aD3fDNkLWCEqrqooaIDY3KqBEd7/J7vSoUAKwT/AUoo+4lqQzKyEGq3+TuVtLGnl+
AAAAAAAA
--------------ms040201060806000805040605--
7 years, 1 month
Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com
According to the issue report, the connection 0's DN appears not only
once, but twice, in some circumstances. Duplicated DN should not have
appeared in server response.
Apart from that, connection 0 does not serve any purpose for LDAP
clients, therefore its connection details are not useful.
What do you think?
Kind regards,
Howard
On 10/04/15 14:29, Michael Ströder wrote:
> hguo(a)suse.com wrote:
>> The patch is a proposed resolution to the issue.
>>
>> To prevent monitor backend from returning invalid result about
>> Connection 0, it will simply not report information about the
>> connection 0.
>
> Indeed I do understand what your patch does.
>
> But what is the real problem with Connection 0 you're trying to solve?
> Note that slapd internally access the database(s). So your monitoring
> checks should simply ignore this Connection 0.
>
> Ciao, Michael.
> .
7 years, 1 month
