openldap-bugs April 2015

openldap-bugs@openldap.org

29 participants
104 discussions

(ITS#8102) syncrepl_entry: be_modify failed (16)
by tpretz＠gmail.com 11 Apr '15

11 Apr '15

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

1 0

Re: (ITS#8101) facsimileTelephoneNumber
by hyc＠symas.com 10 Apr '15

10 Apr '15

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/

1 0

Re: (ITS#8102) syncrepl_entry: be_modify failed (16)
by quanah＠zimbra.com 10 Apr '15

10 Apr '15

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

1 0

(ITS#8102) syncrepl_entry: be_modify failed (16)
by tpretz＠gmail.com 10 Apr '15

10 Apr '15

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

1 0

Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com 10 Apr '15

10 Apr '15

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.

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 10 Apr '15

10 Apr '15

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

1 0

Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com 10 Apr '15

10 Apr '15

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.

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 10 Apr '15

10 Apr '15

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

1 0

Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com 10 Apr '15

10 Apr '15

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

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 10 Apr '15

10 Apr '15

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

1 0

← Newer
1
...
5
6
7
8
9
10
11
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2015