- openldap-bugs - openldap.org

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 07 Apr '16

07 Apr '16

T24gNC83LzE2LCAxMjowNCBBTSwgIm9wZW5sZGFwLWJ1Z3Mgb24gYmVoYWxmIG9mIHF1YW5haEB6 aW1icmEuY29tIiA8b3BlbmxkYXAtYnVncy1ib3VuY2VzQG9wZW5sZGFwLm9yZyBvbiBiZWhhbGYg b2YgcXVhbmFoQHppbWJyYS5jb20+IHdyb3RlOg0KDQo+LS1PbiBUaHVyc2RheSwgQXByaWwgMDcs IDIwMTYgNDoyMiBBTSArMDAwMCBxdWFuYWhAemltYnJhLmNvbSB3cm90ZToNCj4NCj4+IFNvIHRo ZSBjaGFuZ2UgaXMgc3RpbGwgY29ycmVjdGx5IHJlcGxpY2F0ZWQgdG8gdGhlIHJlcGxpY2F0aW5n IE1NUiBub2RlLg0KPg0KPkkgc2VlIHRoZSBzYW1lIGJlaGF2aW9yIHdpdGggdGhlIGV4YW1wbGUg Y29uZmlndXJhdGlvbiB0aGF0IHdhcyBwcm92aWRlZCBhcyANCj53ZWxsLiAgV2hpbGUgdGhlIENT TiBiaXQgbWF5IG5vdCBiZSBsb2dnZWQsIHRoZSBjaGFuZ2UgaXMgcmVwbGljYXRlZCBhcyBpdCAN Cj5zaG91bGQgYmUuDQoNCjxzbmlwPg0KPg0KPlNvIHdoaWxlIHRoZSBsYWNrIG9mIHRoZSAsY3Nu IGJpdCBpcyBhbm5veWluZy4uLiBJIHNlZSBubyBhY3R1YWwgZGF0YSBsb3NzLCANCj5ldGMuDQoN Cg0KUXVhbmFoLA0KDQogIEnigJlsbCBnbyBwZWVyIGRlZXBlciBpbnRvIHRoZSBsb2dzIG9uIHRo ZSBjb25zdW1lciBzaWRlLiAgDQoNCiAgSWYgSSBmaW5kIHRoZSBzYW1lIGhlcmUsIHRoYXQgaW5k aWNhdGVzIHRoZSBwcm92aWRlciBpcyBzYXlpbmcg4oCcdGhlcmUgYXJlIGNoYW5nZXPigJ0gYnV0 IG5vdCBzZW5kaW5nIHRoZSBDU04gYW5kIHN5bmNyZXBsIGlzIHJldHJpZXZpbmcgYW5kIGFwcGx5 aW5nIHRoZSBjaGFuZ2VzLCBidXQgbm90IHVwZGF0aW5nIHRoZSBDU04gaW4gdGhlIERTQSBvZiB0 aGUgY29uc3VtZXIuICBXaGljaCBzdWdnZXN0cyB0aGF0IHN5bmNyZXBsIG5lZWRzIGEgcGF0Y2gg b3IgdGhhdCBJIHNob3VsZCBub3QgYmUgdHJ1c3RpbmcgdGhlIENTTiB2YWx1ZSBpbiB0aGUgY29u c3VtZXLigJlzIERTQSBpbiB0aGUgY2hlY2tfc3luY3JlcGwgc2NyaXB0IChhbHRob3VnaCwgSSBj YW7igJl0IHRoaW5rIG9mIGFub3RoZXIgcXVpY2sgd2F5IHRvIGFzc2VzcyB3aGV0aGVyIHRoZSBw cm92aWRlciBhbmQgY29uc3VtZXIgYXJlIGluIHN5bmMgLSBvZmYgdGhlIHRvcCBvZiBteSBoZWFk KS4gIEV2ZW50dWFsbHksIHN5bmNwcm92IGRvZXMgc2VuZCB0aGUgQ1NOIGFuZCB0aGUgY29uc3Vt ZXLigJlzIENTTiBnZXRzIHVwZGF0ZWQsIHNvIHRoaW5ncyByZXBvcnQgYXMgaGF2aW5nIGNhdWdo dCB1cC4NCg0KLSBGcmFuaw0K

1 0

Re: (ITS#8397) Unable to start LDAP Service in Windows
by charisse.ann.m.jorge＠accenture.com 07 Apr '16

07 Apr '16

--_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We already contacted Hyperion Support regarding this, However, still failed to start the OpenLDAP service. And we're thinking if it's in the setup of OpenLDAP. Kindly advise. Thank you ________________________________ This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise confidential information. If you have received= it in error, please notify the sender immediately and delete the original.= Any other use of the e-mail by you is prohibited. Where allowed by local l= aw, electronic communications with Accenture and its affiliates, including = e-mail and instant messaging (including content), may be scanned by our sys= tems for the purposes of information security and assessment of internal co= mpliance with Accenture policy. ___________________________________________________________________________= ___________ www.accenture.com --_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema= s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html= 40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Hi,<o:p></o:p></p> <p class=3D"MsoNormal">We already contacted Hyperion Support regarding this= , <o:p></o:p></p> <p class=3D"MsoNormal">However, still failed to start the OpenLDAP service.= <o:p></o:p></p> <p class=3D"MsoNormal">And we're thinking if it's in the setup of OpenLDAP.= <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Kindly advise. Thank you<o:p></o:p></p> </div> <br> <hr> <font face=3D"Arial" color=3D"Gray" size=3D"1"><br> This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise confidential information. If you have received= it in error, please notify the sender immediately and delete the original.= Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications w= ith Accenture and its affiliates, including e-mail and instant messaging (i= ncluding content), may be scanned by our systems for the purposes of inform= ation security and assessment of internal compliance with Accenture policy. <br> ___________________________________________________________________________= ___________<br> <br> www.accenture.com<br> </font> </body> </html> --_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_--

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 4:22 AM +0000 quanah(a)zimbra.com wrote: > So the change is still correctly replicated to the replicating MMR node. I see the same behavior with the example configuration that was provided as well. While the CSN bit may not be logged, the change is replicated as it should be. Provider: Apr 6 22:59:28 zre-ldap002 slapd[22212]: slap_queue_csn: queueing 0x4ab3600 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap002 slapd[22212]: slap_graduate_commit_csn: removing 0x4ab3600 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap002 slapd[22212]: syncprov_sendresp: cookie=rid=100 Apr 6 22:59:28 zre-ldap002 slapd[22212]: conn=1003 op=1 RESULT tag=103 err=0 etime=0.084274 text= Replica: Apr 6 22:59:28 zre-ldap003 slapd[7947]: do_syncrep2: rid=100 cookie=rid=100 Apr 6 22:59:28 zre-ldap003 slapd[7947]: slap_queue_csn: queueing 0x37403c0 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap003 slapd[7947]: slap_graduate_commit_csn: removing 0x37403c0 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap003 slapd[7947]: syncrepl_message_to_op: rid=100 be_modify uid=fcs,ou=People,dc=uvm,dc=edu (0) So while the lack of the ,csn bit is annoying... I see no actual data loss, etc. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 4:05 AM +0000 quanah(a)zimbra.com wrote: > --On Thursday, April 07, 2016 12:05 AM +0000 Frank.Swasey(a)uvm.edu wrote: > > Hi Frank, > > Actually, I see this affects all forms of replication. On my ldap > servers it is much more frequent than hourly: > Apr 6 21:56:47 ldap01 slapd[34514]: syncprov_sendresp: to=004, > cookie=rid=102,sid=003 Interestingly, for MMR, this does not result in any data loss, as the changes are replicated w/o problem: MMR node taking writes: Apr 6 21:56:47 ldap01 slapd[34514]: slap_queue_csn: queueing 0x10bfcc80 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap01 slapd[34514]: slap_graduate_commit_csn: removing 0x10bfcc80 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap01 slapd[34514]: conn=2909 op=286509 RESULT tag=103 err=0 etime=0.000935 text= Apr 6 21:56:47 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 MMR node receiving writes: Apr 6 21:56:47 ldap02 slapd[61570]: do_syncrep2: rid=102 cookie=rid=102,sid=003 Apr 6 21:56:47 ldap02 slapd[61570]: slap_queue_csn: queueing 0x80ee240 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: slap_queue_csn: queueing 0x420c2c0 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: syncprov_matchops: skipping original sid 003 Apr 6 21:56:47 ldap02 slapd[61570]: slap_graduate_commit_csn: removing 0x420c2c0 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: slap_graduate_commit_csn: removing 0x80ee240 20160407025647.107497Z#000000#003#000000 So the change is still correctly replicated to the replicating MMR node. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 12:05 AM +0000 Frank.Swasey(a)uvm.edu wrote: Hi Frank, Actually, I see this affects all forms of replication. On my ldap servers it is much more frequent than hourly: Apr 6 20:57:51 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 20:58:33 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:00:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:00:28 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:01:24 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:03:29 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:04:32 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:06:02 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:07:02 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:07:51 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:09:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:10:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:11:03 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:11:26 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:13:03 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:17:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:18:27 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:21:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:23:55 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:25:00 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:25:36 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:26:57 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:27:55 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:29:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:30:38 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:31:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:31:10 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:32:20 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:33:27 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:35:16 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:37:07 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:38:21 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:39:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:40:16 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:41:11 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:42:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:42:59 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:43:32 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:44:31 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:45:50 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:48:01 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:48:36 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:51:00 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:51:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:53:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:54:28 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:55:21 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:56:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:56:47 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:58:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:59:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:01:01 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:01:33 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:02:30 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:03:41 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 12:04 AM +0000 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > On 4/6/16, 4:01 PM, "openldap-bugs on behalf of quanah(a)zimbra.com" > <openldap-bugs-bounces(a)openldap.org on behalf of quanah(a)zimbra.com> wrote: > >> Hi Frank, >> >> I'm going to see if I can reproduce this in my setup with your >> configurations. I did notice that you don't have the syncprov overlay >> loaded on your replica, which is generally recommended. > > Quanah, > > I've never heard that recommendation. Nor, do I find it in the > slapo-syncprov man page or the Administrator's guide discussion of the > syncprov overlay and delta-syncrepl configuration. Please provide a > reference to that recommendation. You just read it. ;) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 07 Apr '16

07 Apr '16

T24gNC82LzE2LCA0OjAxIFBNLCAib3BlbmxkYXAtYnVncyBvbiBiZWhhbGYgb2YgcXVhbmFoQHpp bWJyYS5jb20iIDxvcGVubGRhcC1idWdzLWJvdW5jZXNAb3BlbmxkYXAub3JnIG9uIGJlaGFsZiBv ZiBxdWFuYWhAemltYnJhLmNvbT4gd3JvdGU6DQoNCj5IaSBGcmFuaywNCj4NCj5JJ20gZ29pbmcg dG8gc2VlIGlmIEkgY2FuIHJlcHJvZHVjZSB0aGlzIGluIG15IHNldHVwIHdpdGggeW91ciANCj5j b25maWd1cmF0aW9ucy4gIEkgZGlkIG5vdGljZSB0aGF0IHlvdSBkb24ndCBoYXZlIHRoZSBzeW5j cHJvdiBvdmVybGF5IA0KPmxvYWRlZCBvbiB5b3VyIHJlcGxpY2EsIHdoaWNoIGlzIGdlbmVyYWxs eSByZWNvbW1lbmRlZC4NCg0KUXVhbmFoLA0KDQogIEnigJl2ZSBuZXZlciBoZWFyZCB0aGF0IHJl Y29tbWVuZGF0aW9uLiAgTm9yLCBkbyBJIGZpbmQgaXQgaW4gdGhlIHNsYXBvLXN5bmNwcm92IG1h biBwYWdlIG9yIHRoZSBBZG1pbmlzdHJhdG9y4oCZcyBndWlkZSBkaXNjdXNzaW9uIG9mIHRoZSBz eW5jcHJvdiBvdmVybGF5IGFuZCBkZWx0YS1zeW5jcmVwbCBjb25maWd1cmF0aW9uLiAgUGxlYXNl IHByb3ZpZGUgYSByZWZlcmVuY2UgdG8gdGhhdCByZWNvbW1lbmRhdGlvbi4NCg0KLSBGcmFuaw0K DQo=

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 06 Apr '16

06 Apr '16

--On Wednesday, April 06, 2016 7:58 PM +0000 Frank.Swasey(a)uvm.edu wrote: > SSBoYXZlIGJhY2tlZCBvdXQgdGhlIElUUyM4MjgxIHBhdGNoIGZyb20gbXkgbG9jYWwgYnVpb > GRz > IG9mIDIuNC40MyBhbmQgMi40LjQ0LiBUaGV5IGhhdmUgYm90aCBydW4gd2l0aG91dCBpc3N1Z > SBm > b3IgdHdvIGhvdXJzIGVhY2guICBUaGVyZWZvcmUsIEnigJltIHByZXR0eSBzdXJlIHRoYXQgd > Ghl > IGNhdXNlIG9mIHRoZSBzeW5jcHJvdiBmYWlsdXJlIGlzIHRoYXQgcGF0Y2guICBJdCBtYXkgd > 29y > ayB3ZWxsIGluIGFuIE1NUiBlbnZpcm9ubWVudCwgYnV0IGl0IGlzIGZhaWxpbmcgaW4gYSBza > W5n bGUgbWFzdGVyIHNldHVwLg0KDQotIEZyYW5rDQoNCg0K Hi Frank, I'm going to see if I can reproduce this in my setup with your configurations. I did notice that you don't have the syncprov overlay loaded on your replica, which is generally recommended. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 06 Apr '16

06 Apr '16

SSBoYXZlIGJhY2tlZCBvdXQgdGhlIElUUyM4MjgxIHBhdGNoIGZyb20gbXkgbG9jYWwgYnVpbGRz IG9mIDIuNC40MyBhbmQgMi40LjQ0LiBUaGV5IGhhdmUgYm90aCBydW4gd2l0aG91dCBpc3N1ZSBm b3IgdHdvIGhvdXJzIGVhY2guICBUaGVyZWZvcmUsIEnigJltIHByZXR0eSBzdXJlIHRoYXQgdGhl IGNhdXNlIG9mIHRoZSBzeW5jcHJvdiBmYWlsdXJlIGlzIHRoYXQgcGF0Y2guICBJdCBtYXkgd29y ayB3ZWxsIGluIGFuIE1NUiBlbnZpcm9ubWVudCwgYnV0IGl0IGlzIGZhaWxpbmcgaW4gYSBzaW5n bGUgbWFzdGVyIHNldHVwLg0KDQotIEZyYW5rDQoNCg0K

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 06 Apr '16

06 Apr '16

SSBhbSBidWlsZGluZyBhIHZlcnNpb24gb2YgMi40LjQzIHdpdGggSVRTODI4MSByZW1vdmVkLiAg V2lsbCBzZWUgaWYgdGhhdCByZXNvbHZlcyB0aGUgaXNzdWUuDQoNCuKAlA0KRnJhbmsgU3dhc2V5 DQpTeXN0ZW1zIEFyY2hpdGVjdHVyZSAmIEFkbWluaXN0cmF0aW9uDQoNCg0KDQoNCg0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvcGVubGRhcC1idWdzIDxvcGVubGRhcC1i dWdzLWJvdW5jZXNAb3BlbmxkYXAub3JnPiBvbiBiZWhhbGYgb2YgIkZyYW5rLlN3YXNleUB1dm0u ZWR1IiA8RnJhbmsuU3dhc2V5QHV2bS5lZHU+DQpEYXRlOiBXZWRuZXNkYXksIEFwcmlsIDYsIDIw MTYgYXQgNzo0NSBBTQ0KVG86ICJvcGVubGRhcC1pdHNAb3BlbmxkYXAub3JnIiA8b3BlbmxkYXAt aXRzQG9wZW5sZGFwLm9yZz4NClN1YmplY3Q6IFJlOiAoSVRTIzgzOTYpIHN5bmNwcm92IGhvdXJs eSBmYWlscyB0byBhbnN3ZXIgc3luY3JlcGwNCg0KPldXVnpkR1Z5WkdGNUxDQkpJR0oxYVd4MElH RnVaQ0IwWlhOMFpXUWdNaTQwTGpRMExDQXlMalF1TkRNc0lHRnVaQ0F5TGpRdU5ESWcNCj5kMmww YUc5MWRDQjBhR1VnYm05eWJXRnNJRzF2WkdsbWFXTmhkR2x2Ym5NZ2RHaGhkQ0JKSUcxaGEyVWdk RzhnZEdobElHTnZaR1VnDQo+WW1GelpTNGdJQTBLRFFwSklHaGhkbVVnWm05MWJtUWdkR2hoZENC aWIzUm9JREl1TkM0ME5DQmhibVFnTWk0MExqUXpJR2hoZG1VZw0KPmRHaHBjeUJtWVdsc2RYSmxJ SGRwZEdocGJpQmhiaUJvYjNWeUlHOW1JSE4wWVhKMGFXNW5JSFJvWlNCd2NtbHRZWEo1SUhObGNu WmwNCj5jaUJoYm1RZ2IyNWpaU0JoYmlCb2IzVnlJR0ZtZEdWeUlHbDBJR1pwY25OMElHaGhjSEJs Ym5NdUlDQlVhR1VnTWk0MExqUXlJR052DQo+WkdVZ2FHRnpJR0psWlc0Z2NuVnVibWx1WnlCbWIz SWdiM1psY2lCbWFXWjBaV1Z1SUdodmRYSnpJRzV2ZHlCb1lYTWdibTkwSUdaaA0KPmFXeGxaQ0Jo ZENCaGJHd3VEUW9OQ2xSb1pTQnpZM0pwY0hRZ1NTQjFjMlZrSUhSdklHSjFhV3hrSUhSb1pYTmxJ R2x6SUdGMllXbHMNCj5ZV0pzWlNCb1pYSmxPZzBLRFFwb2RIUndPaTh2ZDNkM0xuVjJiUzVsWkhV dmZtWmpjeTl2Y0dWdWJHUmhjRjlwZEhNdlluVnBiR1F0DQo+YjNCbGJteGtZWEF1YzJnTkNnMEs0 b0NVRFFwR2NtRnVheUJUZDJGelpYa05DbE41YzNSbGJYTWdRWEpqYUdsMFpXTjBkWEpsSUNZZw0K PlFXUnRhVzVwYzNSeVlYUnBiMjROQ2cwSw0KPg0KPg0KPg0K

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 06 Apr '16

06 Apr '16

WWVzdGVyZGF5LCBJIGJ1aWx0IGFuZCB0ZXN0ZWQgMi40LjQ0LCAyLjQuNDMsIGFuZCAyLjQuNDIg d2l0aG91dCB0aGUgbm9ybWFsIG1vZGlmaWNhdGlvbnMgdGhhdCBJIG1ha2UgdG8gdGhlIGNvZGUg YmFzZS4gIA0KDQpJIGhhdmUgZm91bmQgdGhhdCBib3RoIDIuNC40NCBhbmQgMi40LjQzIGhhdmUg dGhpcyBmYWlsdXJlIHdpdGhpbiBhbiBob3VyIG9mIHN0YXJ0aW5nIHRoZSBwcmltYXJ5IHNlcnZl ciBhbmQgb25jZSBhbiBob3VyIGFmdGVyIGl0IGZpcnN0IGhhcHBlbnMuICBUaGUgMi40LjQyIGNv ZGUgaGFzIGJlZW4gcnVubmluZyBmb3Igb3ZlciBmaWZ0ZWVuIGhvdXJzIG5vdyBoYXMgbm90IGZh aWxlZCBhdCBhbGwuDQoNClRoZSBzY3JpcHQgSSB1c2VkIHRvIGJ1aWxkIHRoZXNlIGlzIGF2YWls YWJsZSBoZXJlOg0KDQpodHRwOi8vd3d3LnV2bS5lZHUvfmZjcy9vcGVubGRhcF9pdHMvYnVpbGQt b3BlbmxkYXAuc2gNCg0K4oCUDQpGcmFuayBTd2FzZXkNClN5c3RlbXMgQXJjaGl0ZWN0dXJlICYg QWRtaW5pc3RyYXRpb24NCg0K

1 0

Re: (ITS#8397) Unable to start LDAP Service in Windows
by hyc＠symas.com 06 Apr '16

06 Apr '16

charisse.ann.m.jorge(a)accenture.com wrote: > Full_Name: charisse.ann.m.jorge > Version: 2.3.7 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.248.16.158) > > > Hi > > we are experiencing the same issue as ITS#6106, the only difference is our LDAP > Version is 2.3.7. > > 1) Start the LDAP Service in Windows > 2) System will prompt error: > Windows could not start the Hyperion Foundation OpenLDAP on local computer. > For more information, review the system event log. If this is non-Microsoft > Service, contact the service vendor, and refer to service-specific error code > 16. > > 3) Go to Windows Event Viewer, System Log > Notice that there's an error log with description: > The Hyperion Foundation OpenLDAP Service terminated with service-specific > error 16 > > i tried running slapd.exe -d -1 > > E:\Hyperion\products\Foundation\openLDAP>slapd.exe -d -1 > @(#) $OpenLDAP: slapd 2.3.7 (Sep 28 2005 17:09:57) $ > @DILEEP:/c/opldap15/openldap-2.3.7/servers/slapd > daemon_init: ldap://$J(LOCALHOSTNAMESHORT):58089/ > daemon_init: listen on ldap://$J(LOCALHOSTNAMESHORT):58089/ > daemon_init: 1 listeners to open... > ldap_url_parse_ext(ldap://$J(LOCALHOSTNAMESHORT):58089/) > daemon: invalid host $J(LOCALHOSTNAMESHORT)slapd stopped. > connections_destroy: nothing to destroy. > > please advise. Do as the error message says and contact your service vendor. Apparently that's Hyperion Foundation. Not us. 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

(ITS#8397) Unable to start LDAP Service in Windows
by charisse.ann.m.jorge＠accenture.com 06 Apr '16

06 Apr '16

Full_Name: charisse.ann.m.jorge Version: 2.3.7 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.248.16.158) Hi we are experiencing the same issue as ITS#6106, the only difference is our LDAP Version is 2.3.7. 1) Start the LDAP Service in Windows 2) System will prompt error: Windows could not start the Hyperion Foundation OpenLDAP on local computer. For more information, review the system event log. If this is non-Microsoft Service, contact the service vendor, and refer to service-specific error code 16. 3) Go to Windows Event Viewer, System Log Notice that there's an error log with description: The Hyperion Foundation OpenLDAP Service terminated with service-specific error 16 i tried running slapd.exe -d -1 E:\Hyperion\products\Foundation\openLDAP>slapd.exe -d -1 @(#) $OpenLDAP: slapd 2.3.7 (Sep 28 2005 17:09:57) $ @DILEEP:/c/opldap15/openldap-2.3.7/servers/slapd daemon_init: ldap://$J(LOCALHOSTNAMESHORT):58089/ daemon_init: listen on ldap://$J(LOCALHOSTNAMESHORT):58089/ daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://$J(LOCALHOSTNAMESHORT):58089/) daemon: invalid host $J(LOCALHOSTNAMESHORT)slapd stopped. connections_destroy: nothing to destroy. please advise.

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 06 Apr '16

06 Apr '16

--On Tuesday, April 05, 2016 11:35 PM +0000 Frank.Swasey(a)uvm.edu wrote: It's ok, it is trivial to run through a mime decoder. So the regression was added in 2.4.43. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 06 Apr '16

06 Apr '16

U2Vjb25kIGF0dGVtcHQgLSBzb21ldGhpbmcgYWJvdXQgbXkgZmlyc3QgYXR0ZW1wdCBzZWVtcyB0 byBoYXZlIHRyaXBwZWQgdGhlIHNwYW0gZmlsdGVyIGF0IGdhdXNzLg0KDQpUb2RheSwgSSBoYXZl IGJ1aWx0IGFuZCB0ZXN0ZWQgMi40LjQ0LCAyLjQuNDMsIGFuZCAyLjQuNDIgd2l0aG91dCB0aGUg bm9ybWFsIG1vZGlmaWNhdGlvbnMgdGhhdCBJIG1ha2UgdG8gdGhlIGNvZGUgYmFzZS4gIEkgaGF2 ZSBmb3VuZCB0aGF0IGJvdGggMi40LjQ0IGFuZCAyLjQuNDMgaGF2ZSB0aGlzIGZhaWx1cmUgd2l0 aGluIGFuIGhvdXIgb2Ygc3RhcnRpbmcgdGhlIHByaW1hcnkgc2VydmVyIGFuZCBvbmNlIGFuIGhv dXIgYWZ0ZXIgaXQgZmlyc3QgaGFwcGVucy4gIFRoZSAyLjQuNDIgY29kZSBoYXMgYmVlbiBydW5u aW5nIGZvciBvdmVyIHR3byBob3VycyBub3cgKGFuZCBqdXN0IGFzIGluIG15IHByb2R1Y3Rpb24g ZW52aXJvbm1lbnQpIGhhcyBub3QgZmFpbGVkIGF0IGFsbC4NCg0KVGhlIG9wdGlvbnMgSSBhbSB1 c2luZyB3aXRoIGNvbmZpZ3VyZSBhcmU6DQoNCmV4cG9ydCBDRkxBR1M9Ii1ETkRFQlVHIC1EX1JF RU5UUkFOVCAtZlBJQyINCmV4cG9ydCBMSUJTPSItbHB0aHJlYWQiDQouL2NvbmZpZ3VyZSBcDQog ICAgICAgIC1xIFwNCiAgICAgICAgLS1lbmFibGUtZHluYW1pYyBcDQogICAgICAgIC0tZW5hYmxl LXN0YXRpYyBcDQogICAgICAgIC0td2l0aC10aHJlYWRzPXBvc2l4IFwNCiAgICAgICAgLS13aXRo LXRscz1vcGVuc3NsIFwNCiAgICAgICAgLS13aXRoLWN5cnVzLXNhc2wgXA0KICAgICAgICAtLWVu YWJsZS13cmFwcGVycyBcDQogICAgICAgIC0tZW5hYmxlLXBhc3N3ZCBcDQogICAgICAgIC0tZW5h YmxlLWNsZWFydGV4dCBcDQogICAgICAgIC0tZW5hYmxlLWNyeXB0IFwNCiAgICAgICAgLS1lbmFi bGUtc3Bhc3N3ZCBcDQogICAgICAgIC0tZW5hYmxlLWxtcGFzc3dkIFwNCiAgICAgICAgLS1lbmFi bGUtbW9kdWxlcyBcDQogICAgICAgIC0tZW5hYmxlLWlwdjYgXA0KICAgICAgICBcDQogICAgICAg IC0tZW5hYmxlLXNsYXBkIFwNCiAgICAgICAgLS1lbmFibGUtYmFja2VuZHM9bW9kIFwNCiAgICAg ICAgLS1kaXNhYmxlLW5kYiBcDQogICAgICAgIC0tZGlzYWJsZS1zcWwgXA0KICAgICAgICAtLWRp c2FibGUtcGVybCBcDQogICAgICAgIC0tZGlzYWJsZS1zaGVsbCBcDQogICAgICAgIC0tZW5hYmxl LW92ZXJsYXlzPW1vZA0KDQoNCuKAlA0KRnJhbmsgU3dhc2V5DQpTeXN0ZW1zIEFyY2hpdGVjdHVy ZSAmIEFkbWluaXN0cmF0aW9uDQo=

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 06 Apr '16

06 Apr '16

VG9kYXksIEkgaGF2ZSBidWlsdCBhbmQgdGVzdGVkIDIuNC40NCwgMi40LjQzLCBhbmQgMi40LjQy IHdpdGhvdXQgdGhlIG5vcm1hbCBtb2RpZmljYXRpb25zIHRoYXQgSSBtYWtlIHRvIHRoZSBjb2Rl IGJhc2UuICBJIGhhdmUgZm91bmQgdGhhdCBib3RoIDIuNC40NCBhbmQgMi40LjQzIGhhdmUgdGhp cyBmYWlsdXJlIHdpdGhpbiBhbiBob3VyIG9mIHN0YXJ0aW5nIHRoZSBwcmltYXJ5IHNlcnZlciBh bmQgb25jZSBhbiBob3VyIGFmdGVyIGl0IGZpcnN0IGhhcHBlbnMuICBUaGUgMi40LjQyIGNvZGUg aGFzIGJlZW4gcnVubmluZyBmb3Igb3ZlciB0d28gaG91cnMgbm93IChhbmQganVzdCBhcyBpbiBt eSBwcm9kdWN0aW9uIGVudmlyb25tZW50KSBoYXMgbm90IGZhaWxlZCBhdCBhbGwuDQoNClRoZSBv cHRpb25zIEkgYW0gdXNpbmcgd2l0aCBjb25maWd1cmUgYXJlOg0KDQpleHBvcnQgQ0ZMQUdTPSIt RE5ERUJVRyAtRF9SRUVOVFJBTlQgLWZQSUMiDQpleHBvcnQgTElCUz0iLWxwdGhyZWFkIg0KLi9j b25maWd1cmUgXA0KICAgICAgICAtcSBcDQogICAgICAgIC0tZW5hYmxlLWR5bmFtaWMgXA0KICAg ICAgICAtLWVuYWJsZS1zdGF0aWMgXA0KICAgICAgICAtLXdpdGgtdGhyZWFkcz1wb3NpeCBcDQog ICAgICAgIC0td2l0aC10bHM9b3BlbnNzbCBcDQogICAgICAgIC0td2l0aC1jeXJ1cy1zYXNsIFwN CiAgICAgICAgLS1lbmFibGUtd3JhcHBlcnMgXA0KICAgICAgICAtLWVuYWJsZS1wYXNzd2QgXA0K ICAgICAgICAtLWVuYWJsZS1jbGVhcnRleHQgXA0KICAgICAgICAtLWVuYWJsZS1jcnlwdCBcDQog ICAgICAgIC0tZW5hYmxlLXNwYXNzd2QgXA0KICAgICAgICAtLWVuYWJsZS1sbXBhc3N3ZCBcDQog ICAgICAgIC0tZW5hYmxlLW1vZHVsZXMgXA0KICAgICAgICAtLWVuYWJsZS1pcHY2IFwNCiAgICAg ICAgXA0KICAgICAgICAtLWVuYWJsZS1zbGFwZCBcDQogICAgICAgIC0tZW5hYmxlLWJhY2tlbmRz PW1vZCBcDQogICAgICAgIC0tZGlzYWJsZS1uZGIgXA0KICAgICAgICAtLWRpc2FibGUtc3FsIFwN CiAgICAgICAgLS1kaXNhYmxlLXBlcmwgXA0KICAgICAgICAtLWRpc2FibGUtc2hlbGwgXA0KICAg ICAgICAtLWVuYWJsZS1vdmVybGF5cz1tb2QNCg0KDQrigJQNCkZyYW5rIFN3YXNleQ0KU3lzdGVt cyBBcmNoaXRlY3R1cmUgJiBBZG1pbmlzdHJhdGlvbg0KDQoNCg0KDQoNCg==

1 0

Re: (ITS#8395) DH Params code causes startTLS failure while slapd initializes the code
by quanah＠zimbra.com 05 Apr '16

05 Apr '16

--On Sunday, April 03, 2016 3:34 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) Closing this ITS, it was related to a bug in the code in our side that sets the DH Param bits for slapd, that has a race condition, where the file may be 0 sized initially. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 04 Apr '16

04 Apr '16

Full_Name: Francis Swasey Version: 2.4.44 OS: Red Hat Enterprise Linux Server release 7.2 (Maipo) URL: http://www.uvm.edu/~fcs/openldap_its/syncprov_files.tar.gz Submission from: (NULL) (132.198.104.198) Once an hour, the primary server logs a syncprov_sendresp that does not include a csn. When that happens, the replica misses that there were changes and does not update and therefore falls behind. The URI provides files for the primary and replica. replica/slapd_db.ldif -- starting database replica/slapd.conf -- replica's slapd configuration file (you'll need to create your own ssl certs) replica/syncrepl_audit.sh -- Runs on the replica (edit the email address and the path to check_syncrepl replica/check_syncrepl -- Used by nagios to report csn being in sync or not primary/slapd_db.ldif -- starting database (almost exactly like the replica's version) primary/slapd.conf -- primary's slapd configuration file (you'll need to create your own ssl certs) primary/syncprov_audit.sh -- greps the system log (edit the path) looking for the syncprov error primary/makechanges.sh -- edit to change the name of the ldap server and run this to make constant changes The bad log entries that coincide with check_syncrepl finding the replica has fallen behind are like: Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 They appear once an hour.

1 0

Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by bdallen＠nps.edu 04 Apr '16

04 Apr '16

My initial report was garbled. What I mean is that a protection violation occurs in mdb.c when I add a 13'th item to a multiset and I compile with one of the mentioned compilers and with -fPIC -O3. The code works fine when compiled with older GCC compilers or with -O0 or with -fno-strict-aliasing. Given what I read at https://gcc.gnu.org/bugs/ under section "Casting does not work as expected when optimization is turned on", I suspect the problem is simply that a pointer variable is not following the ISO C aliasing rules and breaks with the new, more aggressive compiler optimization. Here is the part that fails: for (i=0; i<NUMKEYS(fp); i++) mp->mp_ptrs[i] = fp->mp_ptrs[i] + offset; If this turns out to not be straightforward, I can try building a small test program to reproduce the problem. On 04/03/2016 09:44 AM, Howard Chu wrote: > bdallen(a)nps.edu wrote: >> Full_Name: Bruce Allen >> Version: 2.4.44 >> OS: Fedora 23 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (205.155.65.226) >> >> >> LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when >> compiled >> using these compilers: >> * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) >> * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW >> 5.2.0-1.fc23) >> >> The crash happens afterrititing the 12'th item (with the same key but >> different >> value using flags MDB_NODUPDATA and MDB_DUPSORT). > > Your message appears garbled here. Please send a test case with steps > to reproduce. >> >> The problem goes away when compiling mdb.c with the >> -fno-strict-aliasing flag. >> >> > >

1 0

Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by hyc＠symas.com 03 Apr '16

03 Apr '16

bdallen(a)nps.edu wrote: > Full_Name: Bruce Allen > Version: 2.4.44 > OS: Fedora 23 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (205.155.65.226) > > > LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when compiled > using these compilers: > * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) > * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW 5.2.0-1.fc23) > > The crash happens afterrititing the 12'th item (with the same key but different > value using flags MDB_NODUPDATA and MDB_DUPSORT). Your message appears garbled here. Please send a test case with steps to reproduce. > > The problem goes away when compiling mdb.c with the -fno-strict-aliasing flag. > > -- -- 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

(ITS#8395) DH Params code causes startTLS failure while slapd initializes the code
by quanah＠openldap.org 03 Apr '16

03 Apr '16

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) While testing the new DH params code for slapd, we found that there is an interval in which slapd will break for startTLS connections while it loads in the DH key. Example: Slapd is up and running, accepts startTLS connections just fine: Apr 2 21:13:08 zre-ldap002 slapd[4844]: conn=1004 fd=13 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=AES256-SHA256 Then we update olcTLSDHParamFile to add a DH key: Apr 2 21:13:09 zre-ldap002 slapd[4844]: conn=1005 op=22 MOD dn="cn=config" Apr 2 21:13:09 zre-ldap002 slapd[4844]: conn=1005 op=22 MOD attr=olcTLSDHParamFile Immediately after this, all startTLS attempts fail for the next few minutes: Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 fd=14 ACCEPT from IP=10.137.242.52:48327 (IP=10.137.242.52:389) Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 STARTTLS Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 RESULT oid= err=52 etime=0.000078 text=Could not initialize TLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1008 op=1 UNBIND Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1008 fd=14 closed Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 fd=14 ACCEPT from IP=10.137.242.52:48328 (IP=10.137.242.52:389) Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 STARTTLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 RESULT oid= err=52 etime=0.000054 text=Could not initialize TLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=1 UNBIND Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 fd=14 closed Apr 2 21:13:17 zre-ldap002 slapd[4844]: connD1D1010 fd=14 ACCEPT from IP=10.137.242.52:48329 (IP=10.137.242.52:389) Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 STARTTLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 RESULT oid= err=52 etime=0.000124 text=Could not initialize TLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=1 UNBIND Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 fd=14 closed Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 fd=14 ACCEPT from IP=10.137.242.52:48330 (IP=10.137.242.52:389) Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=0 STARTTLS Apr 2 21:13:18 zre-lda0202 slapd[4844]: conn=1011 op=0 RESULT oid= err=52 etime=0.000075 text=Could not initialize TLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=1 UNBIND Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 fd=14 closed Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 fd=14 ACCEPT from IP=10.137.242.52:48331 (IP=10.137.242.52:389) Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 STARTTLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 RESULT oid= err=52 etime=0.000098 text=Could not initialize TLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=1 UNBIND Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 fd=14 closed Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 fd=14 ACCEPT from IP=10.137.242.52:48332 (IP=10.137.242.52:389) Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 STARTTLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 RESULT oid= err=52 etime=0.000062 text=Could not initialize TLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=1 UNBIND Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 fd=14 closed Apr 2 21:13"22 zre-ldap0 s slapd[4844]: conn=1014 fd=14 ACCEPT from IP=10.137.242.52:48333 (IP=10.137.242.52:389) Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 STARTTLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 RESULT oid= err=52 etime=0.000108 text=Could not initialize TLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=1 UNBIND Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 fd=14 closed Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 fd=14 ACCEPT from IP=10.137.242.52:48334 (IP=10.137.242.52:389) Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 STARTTLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 RESULT oid= err=52 etime=0.000066 text=Could not initialize TLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=1 UNBIND .... Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022d%d=14 ACCEPT from IP=10.137.242.52:48339 (IP=10.137.242.52:389) Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 STARTTLS Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 RESULT oid= err=52 etime=0.000143 text=Could not initialize TLS Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 fd=14 closed (connection lost) Eventually it recovers: Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 fd=14 ACCEPT from IP=10.137.242.52:48340 (IP=10.137.242.52:389) Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 op=0 STARTTLS Apr 2 21:16:02 zre-ldap002 slapd[4844]: connD1D1027 op=0 RESULT oid= err=0 etime=0.000085 text= Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 fd=14 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.2 tls_cipher=AES128-SHA256 My guess is that startTLS is essentially broken while slapd spends time loading in the DH key. I would think that during this time, slapd should be deferring connections rather than accepting them immediately.

1 0

(ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by bdallen＠nps.edu 02 Apr '16

02 Apr '16

Full_Name: Bruce Allen Version: 2.4.44 OS: Fedora 23 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (205.155.65.226) LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when compiled using these compilers: * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW 5.2.0-1.fc23) The crash happens afterrititing the 12'th item (with the same key but different value using flags MDB_NODUPDATA and MDB_DUPSORT). The problem goes away when compiling mdb.c with the -fno-strict-aliasing flag.

1 0

(ITS#8393) LMDB - MDB_GET_BOTH broken on non-dup value
by hyc＠openldap.org 28 Mar '16

28 Mar '16

Full_Name: Howard Chu Version: 0.9.18 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.228.110) Submitted by: hyc Using mdb_cursor_get(MDB_GET_BOTH) doesn't return the data item if the record is not a dup (i.e., there's only a single value under the key) even though it matches. This doesn't affect slapd because (1) when we use this command, the key always has more than 1 value and (2) when we use it, the data item we passed in is exactly the same as what we would get returned, on a match. This affects other apps where both (1) and (2) are not true, e.g. a compare function is used that only compares a subset of the data, in order to retrieve the full record.

1 0

Re: (ITS#8392) Opening multiple databases from the same process
by matthew＠wellquite.org 27 Mar '16

27 Mar '16

Fixed. The short version is it's definitely a problem of my own making, though it's not related to threading. It's an oversight in the design of my own bindings which only causes an issue when you open multiple databases at the same time. I shall be able to fix without a problem in my bindings. Thank you for your help, and sorry for wasting your time. Kind regards, Matthew

1 0

Re: (ITS#8392) Opening multiple databases from the same process
by hyc＠symas.com 27 Mar '16

27 Mar '16

Nothing immediately obvious jumps out. You might try adding some mdb_page_list() calls in here, maybe at each point where it pushes a new page onto the cursor. -- -- 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#8392) Opening multiple databases from the same process
by matthew＠wellquite.org 26 Mar '16

26 Mar '16

--hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > One problem is that the debug output gives no indication of which thread > is which so it seems pretty tricky to separate out the different calls. > Do you have any hints or tricks for doing this? Ok, so I altered the DPRINTF so that it gets the current thread id too: fprintf(stderr, "%s:%d:%lu " fmt "\n", mdb_func_, __LINE__, syscall(__NR_gettid), __VA_ARGS__) I also added some DPUTS to the start of every function in the API. New log attached. Essentially, there are four threads of interest: 7036 - write txns for /tmp/data1 7039 - read txns (incl cursor) for /tmp/data1 7040 - write txns for /tmp/data2 7041 - read txns (incl cursor) for /tmp/data2 As there are no writes going on, the write threads do no work once the envs and dbis are created and opened. In this run, it's 7039 that finds the usual problem. If we just grep for 7039 from the log, we get (edited highlights): mdb_txn_begin:2860:7039 begin txn 1862r 0x7f4034000a10 on mdbenv 0xd483c0, root page 417 ... mdb_get:5570:7039 mdb_get mdb_get:5576:7039 ===> get db 4 key [00000000000000010000000000000001311e7dc5] ... mdb_cursor_set:6002:7039 ==> cursor placed on key [00000000000000010000000000000001311e7dc5] mdb_txn_reset:2990:7039 mdb_txn_reset mdb_txn_end:2919:7039 mdb_txn_end mdb_txn_end:2931:7039 reset txn 1862r 0x7f4034000a10 on mdbenv 0xd483c0, root page 417 ... now we start up /tmp/data2 in the other threads. When we next see 7039 return: mdb_txn_renew:2749:7039 mdb_txn_renew mdb_txn_renew:2759:7039 renew txn 1862r 0x7f4034000a10 on mdbenv 0xd483c0, root page 417 mdb_cursor_open:7408:7039 mdb_cursor_open mdb_page_search:5445:7039 db 1 root page 417 has flags 0x2 mdb_page_search_root:5342:7039 found leaf page 417 for key [5472616e73616374696f6e73] mdb_node_search:5091:7039 searching 5 keys in leaf page 417 mdb_node_search:5135:7039 found leaf index 2 [5472616e73616374696f6e52656673], rc = 8448 mdb_node_search:5135:7039 found leaf index 3 [5472616e73616374696f6e73], rc = 0 mdb_page_search:5445:7039 db 4 root page 276 has flags 0x1 mdb_cursor_get:6103:7039 mdb_cursor_get mdb_cursor_first:6011:7039 mdb_cursor_first mdb_page_search:5445:7039 db 4 root page 276 has flags 0x1 mdb_page_search_root:5290:7039 branch page 276 has 2 keys mdb_page_search_root:5296:7039 found index 0 to page 710 mdb_cursor_push:5202:7039 pushing page 710 on db 4 cursor 0x7f4034000bd0 mdb_page_search_root:5290:7039 branch page 710 has 134 keys mdb_page_search_root:5296:7039 found index 0 to page 43 mdb_cursor_push:5202:7039 pushing page 43 on db 4 cursor 0x7f4034000bd0 mdb_page_search_root:5342:7039 found leaf page 43 for key [null] ... at this point the error is detected and we start tidying up. >From the tids that are being logged, it doesn't appear to me that anything's up with the threading. It looks like there's some issue with opening a cursor in a read only txn that has already been reset and renewed. The strange thing is that this only happens when this program is running across more than one database. With a single database it never goes wrong. So it seems like there's some interaction between opening a second db and an existing db (with reset txns?). Many thanks for your time. Matthew --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=log GoshawkDBConsistencyChecker 2016/03/26 22:24:37.798236 [./consistencychecker /tmp/data1 /tmp/data2] GoshawkDBConsistencyChecker 2016/03/26 22:24:37.798527 ...loading from /tmp/data1 GoshawkDBConsistencyChecker 2016/03/26 22:24:37.798558 Starting disk server on /tmp/data1 mdb_env_create:3862:7036 mdb_env_create mdb_env_open:4702:7036 mdb_env_open mdb_env_open2:4192:7036 opened database version 1, pagesize 4096 mdb_env_open2:4193:7036 using meta page 0 mdb_env_open2:4194:7036 depth: 1 mdb_env_open2:4195:7036 entries: 5 mdb_env_open2:4196:7036 branch pages: 0 mdb_env_open2:4197:7036 leaf pages: 1 mdb_env_open2:4198:7036 overflow pages: 0 mdb_env_open2:4199:7036 root: 417 mdb_env_open:4821:7036 opened dbenv 0xd483c0 mdb_txn_begin:2767:7036 mdb_txn_begin mdb_txn_begin:2860:7036 begin txn 1863w 0xd49660 on mdbenv 0xd483c0, root page 417 mdb_cursor_set:5812:7036 mdb_cursor_set mdb_page_search:5445:7036 db 1 root page 417 has flags 0x2 mdb_page_search_root:5342:7036 found leaf page 417 for key [5472616e73616374696f6e52656673] mdb_node_search:5091:7036 searching 5 keys in leaf page 417 mdb_node_search:5135:7036 found leaf index 2 [5472616e73616374696f6e52656673], rc = 0 mdb_cursor_set:6002:7036 ==> cursor placed on key [5472616e73616374696f6e52656673] mdb_cursor_set:5812:7036 mdb_cursor_set mdb_page_search:5445:7036 db 1 root page 417 has flags 0x2 mdb_page_search_root:5342:7036 found leaf page 417 for key [56617273] mdb_node_search:5091:7036 searching 5 keys in leaf page 417 mdb_node_search:5135:7036 found leaf index 2 [5472616e73616374696f6e52656673], rc = 2 mdb_node_search:5135:7036 found leaf index 3 [5472616e73616374696f6e73], rc = 2 mdb_node_search:5135:7036 found leaf index 4 [56617273], rc = 0 mdb_cursor_set:6002:7036 ==> cursor placed on key [56617273] mdb_cursor_set:5812:7036 mdb_cursor_set mdb_page_search:5445:7036 db 1 root page 417 has flags 0x2 mdb_page_search_root:5342:7036 found leaf page 417 for key [5472616e73616374696f6e73] mdb_node_search:5091:7036 searching 5 keys in leaf page 417 mdb_node_search:5135:7036 found leaf index 2 [5472616e73616374696f6e52656673], rc = 8448 mdb_node_search:5135:7036 found leaf index 3 [5472616e73616374696f6e73], rc = 0 mdb_cursor_set:6002:7036 ==> cursor placed on key [5472616e73616374696f6e73] mdb_txn_commit:3361:7036 mdb_txn_commit mdb_txn_end:2919:7036 mdb_txn_end mdb_txn_end:2931:7036 empty-commit txn 1863w 0xd49660 on mdbenv 0xd483c0, root page 417 mdb_txn_begin:2767:7039 mdb_txn_begin mdb_txn_begin:2860:7039 begin txn 1862r 0x7f4034000a10 on mdbenv 0xd483c0, root page 417 mdb_txn_renew:2749:7039 mdb_txn_renew mdb_txn_abort:3004:7039 mdb_txn_abort mdb_txn_end:2919:7039 mdb_txn_end mdb_txn_end:2931:7039 abort txn 1862r 0x7f4034000a10 on mdbenv 0xd483c0, root page 417 mdb_txn_begin:2767:7039 mdb_txn_begin mdb_txn_begin:2860:7039 begin txn 1862r 0x7f4034000a10 on mdbenv 0xd483c0, root page 417 mdb_get:5570:7039 mdb_get mdb_get:5576:7039 ===> get db 3 key [0000000000000000000000000000000000000000] mdb_page_search:5445:7039 db 1 root page 417 has flags 0x2 mdb_page_search_root:5342:7039 found leaf page 417 for key [56617273] mdb_node_search:5091:7039 searching 5 keys in leaf page 417 mdb_node_search:5135:7039 found leaf index 2 [5472616e73616374696f6e52656673], rc = 2 mdb_node_search:5135:7039 found leaf index 3 [5472616e73616374696f6e73], rc = 2 mdb_node_search:5135:7039 found leaf index 4 [56617273], rc = 0 mdb_page_search:5445:7039 db 3 root page 471 has flags 0x1 mdb_cursor_set:5812:7039 mdb_cursor_set mdb_page_search:5445:7039 db 3 root page 471 has flags 0x1 mdb_page_search_root:5290:7039 branch page 471 has 3 keys mdb_page_search_root:5296:7039 found index 0 to page 628 mdb_node_search:5091:7039 searching 3 keys in branch page 471 mdb_node_search:5138:7039 found branch index 1 [000000000000011c0000000600000001311e7dc5 -> 725], rc = -1 mdb_page_search_root:5314:7039 following index 0 for key [0000000000000000000000000000000000000000] mdb_cursor_push:5202:7039 pushing page 628 on db 3 cursor 0x7f403c27b6b0 mdb_page_search_root:5290:7039 branch page 628 has 68 keys mdb_page_search_root:5296:7039 found index 0 to page 137 mdb_node_search:5091:7039 searching 68 keys in branch page 628 mdb_node_search:5138:7039 found branch index 34 [00000000000000780000000600000001311e7dc5 -> 138], rc = -30720 mdb_node_search:5138:7039 found branch index 17 [00000000000000220000000600000001311e7dc5 -> 88], rc = -8704 mdb_node_search:5138:7039 found branch index 8 [000000000000000e0000000600000001311e7dc5 -> 50], rc = -3584 mdb_node_search:5138:7039 found branch index 4 [00000000000000030000000500000001311e7dc5 -> 52], rc = -768 mdb_node_search:5138:7039 found branch index 2 [00000000000000010000000300000001311e7dc5 -> 1401], rc = -256 mdb_node_search:5138:7039 found branch index 1 [00000000000000000000000600000001311e7dc5 -> 983], rc = -1536 mdb_page_search_root:5314:7039 following index 0 for key [0000000000000000000000000000000000000000] mdb_cursor_push:5202:7039 pushing page 137 on db 3 cursor 0x7f403c27b6b0 mdb_page_search_root:5342:7039 found leaf page 137 for key [0000000000000000000000000000000000000000] mdb_node_search:5091:7039 searching 6 keys in leaf page 137 mdb_node_search:5135:7039 found leaf index 2 [000000000000000000000000000000015b297cbd], rc = -256 mdb_node_search:5135:7039 found leaf index 0 [0000000000000000000000000000000000000000], rc = 0 mdb_cursor_set:6002:7039 ==> cursor placed on key [0000000000000000000000000000000000000000] mdb_get:5570:7039 mdb_get mdb_get:5576:7039 ===> get db 4 key [00000000000000010000000000000001311e7dc5] mdb_page_search:5445:7039 db 1 root page 417 has flags 0x2 mdb_page_search_root:5342:7039 found leaf page 417 for key [5472616e73616374696f6e73] mdb_node_search:5091:7039 searching 5 keys in leaf page 417 mdb_node_search:5135:7039 found leaf index 2 [5472616e73616374696f6e52656673], rc = 8448 mdb_node_search:5135:7039 found leaf index 3 [5472616e73616374696f6e73], rc = 0 mdb_page_search:5445:7039 db 4 root page 276 has flags 0x1 mdb_cursor_set:5812:7039 mdb_cursor_set mdb_page_search:5445:7039 db 4 root page 276 has flags 0x1 mdb_page_search_root:5290:7039 branch page 276 has 2 keys mdb_page_search_root:5296:7039 found index 0 to page 710 mdb_node_search:5091:7039 searching 2 keys in branch page 276 mdb_node_search:5138:7039 found branch index 1 [00000000000005df00000000000000015b297cbd -> 449], rc = -5 mdb_page_search_root:5314:7039 following index 0 for key [00000000000000010000000000000001311e7dc5] mdb_cursor_push:5202:7039 pushing page 710 on db 4 cursor 0x7f403c27b6b0 mdb_page_search_root:5290:7039 branch page 710 has 134 keys mdb_page_search_root:5296:7039 found index 0 to page 43 mdb_node_search:5091:7039 searching 134 keys in branch page 710 mdb_node_search:5138:7039 found branch index 67 [00000000000002e10000000000000001b1f3f9b0 -> 344], rc = -2 mdb_node_search:5138:7039 found branch index 33 [00000000000000bd0000000000000001311e7dc5 -> 336], rc = -48128 mdb_node_search:5138:7039 found branch index 16 [000000000000005700000000000000015b297cbd -> 123], rc = -22016 mdb_node_search:5138:7039 found branch index 8 [000000000000001d0000000000000001311e7dc5 -> 135], rc = -7168 mdb_node_search:5138:7039 found branch index 4 [00000000000000100000000600000001311e7dc5 -> 19], rc = -3840 mdb_node_search:5138:7039 found branch index 2 [000000000000000200000000000000015b297cbd -> 109], rc = -256 mdb_node_search:5138:7039 found branch index 1 [00000000000000010000000000000001311e7dc5 -> 5], rc = 0 mdb_page_search_root:5314:7039 following index 1 for key [00000000000000010000000000000001311e7dc5] mdb_cursor_push:5202:7039 pushing page 5 on db 4 cursor 0x7f403c27b6b0 mdb_page_search_root:5342:7039 found leaf page 5 for key [00000000000000010000000000000001311e7dc5] mdb_node_search:5091:7039 searching 3 keys in leaf page 5 mdb_node_search:5135:7039 found leaf index 1 [00000000000000010000000000000001b1f3f9b0], rc = -128 mdb_node_search:5135:7039 found leaf index 0 [00000000000000010000000000000001311e7dc5], rc = 0 mdb_cursor_set:6002:7039 ==> cursor placed on key [00000000000000010000000000000001311e7dc5] mdb_txn_reset:2990:7039 mdb_txn_reset mdb_txn_end:2919:7039 mdb_txn_end mdb_txn_end:2931:7039 reset txn 1862r 0x7f4034000a10 on mdbenv 0xd483c0, root page 417 GoshawkDBConsistencyChecker 2016/03/26 22:24:37.799971 ...loading from /tmp/data2 GoshawkDBConsistencyChecker 2016/03/26 22:24:37.800025 Starting disk server on /tmp/data2 mdb_env_create:3862:7040 mdb_env_create mdb_env_open:4702:7040 mdb_env_open mdb_env_open2:4192:7040 opened database version 1, pagesize 4096 mdb_env_open2:4193:7040 using meta page 1 mdb_env_open2:4194:7040 depth: 1 mdb_env_open2:4195:7040 entries: 5 mdb_env_open2:4196:7040 branch pages: 0 mdb_env_open2:4197:7040 leaf pages: 1 mdb_env_open2:4198:7040 overflow pages: 0 mdb_env_open2:4199:7040 root: 1291 mdb_env_open:4821:7040 opened dbenv 0x7f402c0008c0 mdb_txn_begin:2767:7040 mdb_txn_begin mdb_txn_begin:2860:7040 begin txn 1796w 0x7f402c001b80 on mdbenv 0x7f402c0008c0, root page 1291 mdb_cursor_set:5812:7040 mdb_cursor_set mdb_page_search:5445:7040 db 1 root page 1291 has flags 0x2 mdb_page_search_root:5342:7040 found leaf page 1291 for key [5472616e73616374696f6e73] mdb_node_search:5091:7040 searching 5 keys in leaf page 1291 mdb_node_search:5135:7040 found leaf index 2 [5472616e73616374696f6e52656673], rc = 8448 mdb_node_search:5135:7040 found leaf index 3 [5472616e73616374696f6e73], rc = 0 mdb_cursor_set:6002:7040 ==> cursor placed on key [5472616e73616374696f6e73] mdb_cursor_set:5812:7040 mdb_cursor_set mdb_page_search:5445:7040 db 1 root page 1291 has flags 0x2 mdb_page_search_root:5342:7040 found leaf page 1291 for key [5472616e73616374696f6e52656673] mdb_node_search:5091:7040 searching 5 keys in leaf page 1291 mdb_node_search:5135:7040 found leaf index 2 [5472616e73616374696f6e52656673], rc = 0 mdb_cursor_set:6002:7040 ==> cursor placed on key [5472616e73616374696f6e52656673] mdb_cursor_set:5812:7040 mdb_cursor_set mdb_page_search:5445:7040 db 1 root page 1291 has flags 0x2 mdb_page_search_root:5342:7040 found leaf page 1291 for key [56617273] mdb_node_search:5091:7040 searching 5 keys in leaf page 1291 mdb_node_search:5135:7040 found leaf index 2 [5472616e73616374696f6e52656673], rc = 2 mdb_node_search:5135:7040 found leaf index 3 [5472616e73616374696f6e73], rc = 2 mdb_node_search:5135:7040 found leaf index 4 [56617273], rc = 0 mdb_cursor_set:6002:7040 ==> cursor placed on key [56617273] mdb_txn_commit:3361:7040 mdb_txn_commit mdb_txn_end:2919:7040 mdb_txn_end mdb_txn_end:2931:7040 empty-commit txn 1796w 0x7f402c001b80 on mdbenv 0x7f402c0008c0, root page 1291 mdb_txn_begin:2767:7041 mdb_txn_begin mdb_txn_begin:2860:7041 begin txn 1795r 0x7f4030000a10 on mdbenv 0x7f402c0008c0, root page 1291 mdb_txn_renew:2749:7041 mdb_txn_renew mdb_txn_abort:3004:7041 mdb_txn_abort mdb_txn_end:2919:7041 mdb_txn_end mdb_txn_end:2931:7041 abort txn 1795r 0x7f4030000a10 on mdbenv 0x7f402c0008c0, root page 1291 mdb_txn_begin:2767:7041 mdb_txn_begin mdb_txn_begin:2860:7041 begin txn 1795r 0x7f4030000a10 on mdbenv 0x7f402c0008c0, root page 1291 mdb_get:5570:7041 mdb_get mdb_get:5576:7041 ===> get db 4 key [0000000000000000000000000000000000000000] mdb_page_search:5445:7041 db 1 root page 1291 has flags 0x2 mdb_page_search_root:5342:7041 found leaf page 1291 for key [56617273] mdb_node_search:5091:7041 searching 5 keys in leaf page 1291 mdb_node_search:5135:7041 found leaf index 2 [5472616e73616374696f6e52656673], rc = 2 mdb_node_search:5135:7041 found leaf index 3 [5472616e73616374696f6e73], rc = 2 mdb_node_search:5135:7041 found leaf index 4 [56617273], rc = 0 mdb_page_search:5445:7041 db 4 root page 530 has flags 0x1 mdb_cursor_set:5812:7041 mdb_cursor_set mdb_page_search:5445:7041 db 4 root page 530 has flags 0x1 mdb_page_search_root:5290:7041 branch page 530 has 3 keys mdb_page_search_root:5296:7041 found index 0 to page 535 mdb_node_search:5091:7041 searching 3 keys in branch page 530 mdb_node_search:5138:7041 found branch index 1 [000000000000010b0000000600000001311e7dc5 -> 1361], rc = -1 mdb_page_search_root:5314:7041 following index 0 for key [0000000000000000000000000000000000000000] mdb_cursor_push:5202:7041 pushing page 535 on db 4 cursor 0x7f403b2796b0 mdb_page_search_root:5290:7041 branch page 535 has 68 keys mdb_page_search_root:5296:7041 found index 0 to page 35 mdb_node_search:5091:7041 searching 68 keys in branch page 535 mdb_node_search:5138:7041 found branch index 34 [00000000000000700000000600000001311e7dc5 -> 262], rc = -28672 mdb_node_search:5138:7041 found branch index 17 [00000000000000210000000600000001311e7dc5 -> 41], rc = -8448 mdb_node_search:5138:7041 found branch index 8 [000000000000000f0000000600000001311e7dc5 -> 383], rc = -3840 mdb_node_search:5138:7041 found branch index 4 [00000000000000040000000600000001311e7dc5 -> 97], rc = -1024 mdb_node_search:5138:7041 found branch index 2 [00000000000000010000000300000001311e7dc5 -> 568], rc = -256 mdb_node_search:5138:7041 found branch index 1 [00000000000000000000000600000001311e7dc5 -> 197], rc = -1536 mdb_page_search_root:5314:7041 following index 0 for key [0000000000000000000000000000000000000000] mdb_cursor_push:5202:7041 pushing page 35 on db 4 cursor 0x7f403b2796b0 mdb_page_search_root:5342:7041 found leaf page 35 for key [0000000000000000000000000000000000000000] mdb_node_search:5091:7041 searching 6 keys in leaf page 35 mdb_node_search:5135:7041 found leaf index 2 [000000000000000000000000000000015b297cbd], rc = -256 mdb_node_search:5135:7041 found leaf index 0 [0000000000000000000000000000000000000000], rc = 0 mdb_cursor_set:6002:7041 ==> cursor placed on key [0000000000000000000000000000000000000000] mdb_get:5570:7041 mdb_get mdb_get:5576:7041 ===> get db 2 key [00000000000000010000000000000001311e7dc5] mdb_page_search:5445:7041 db 1 root page 1291 has flags 0x2 mdb_page_search_root:5342:7041 found leaf page 1291 for key [5472616e73616374696f6e73] mdb_node_search:5091:7041 searching 5 keys in leaf page 1291 mdb_node_search:5135:7041 found leaf index 2 [5472616e73616374696f6e52656673], rc = 8448 mdb_node_search:5135:7041 found leaf index 3 [5472616e73616374696f6e73], rc = 0 mdb_page_search:5445:7041 db 2 root page 1304 has flags 0x1 mdb_cursor_set:5812:7041 mdb_cursor_set mdb_page_search:5445:7041 db 2 root page 1304 has flags 0x1 mdb_page_search_root:5290:7041 branch page 1304 has 2 keys mdb_page_search_root:5296:7041 found index 0 to page 238 mdb_node_search:5091:7041 searching 2 keys in branch page 1304 mdb_node_search:5138:7041 found branch index 1 [00000000000002cc0000000000000001311e7dc5 -> 1305], rc = -2 mdb_page_search_root:5314:7041 following index 0 for key [00000000000000010000000000000001311e7dc5] mdb_cursor_push:5202:7041 pushing page 238 on db 2 cursor 0x7f403b2796b0 mdb_page_search_root:5290:7041 branch page 238 has 68 keys mdb_page_search_root:5296:7041 found index 0 to page 2 mdb_node_search:5091:7041 searching 68 keys in branch page 238 mdb_node_search:5138:7041 found branch index 34 [00000000000000bd0000000000000001311e7dc5 -> 57], rc = -48128 mdb_node_search:5138:7041 found branch index 17 [000000000000005c0000000000000001311e7dc5 -> 18], rc = -23296 mdb_node_search:5138:7041 found branch index 8 [000000000000001d0000000000000001311e7dc5 -> 151], rc = -7168 mdb_node_search:5138:7041 found branch index 4 [000000000000000e0000000000000001311e7dc5 -> 28], rc = -3328 mdb_node_search:5138:7041 found branch index 2 [000000000000000200000000000000015b297cbd -> 133], rc = -256 mdb_node_search:5138:7041 found branch index 1 [00000000000000010000000000000001311e7dc5 -> 8], rc = 0 mdb_page_search_root:5314:7041 following index 1 for key [00000000000000010000000000000001311e7dc5] mdb_cursor_push:5202:7041 pushing page 8 on db 2 cursor 0x7f403b2796b0 mdb_page_search_root:5342:7041 found leaf page 8 for key [00000000000000010000000000000001311e7dc5] mdb_node_search:5091:7041 searching 3 keys in leaf page 8 mdb_node_search:5135:7041 found leaf index 1 [00000000000000010000000000000001b1f3f9b0], rc = -128 mdb_node_search:5135:7041 found leaf index 0 [00000000000000010000000000000001311e7dc5], rc = 0 mdb_cursor_set:6002:7041 ==> cursor placed on key [00000000000000010000000000000001311e7dc5] mdb_txn_reset:2990:7041 mdb_txn_reset mdb_txn_end:2919:7041 mdb_txn_end mdb_txn_end:2931:7041 reset txn 1795r 0x7f4030000a10 on mdbenv 0x7f402c0008c0, root page 1291 mdb_txn_renew:2749:7041 mdb_txn_renew mdb_txn_renew:2759:7041 renew txn 1795r 0x7f4030000a10 on mdbenv 0x7f402c0008c0, root page 1291 mdb_cursor_open:7408:7041 mdb_cursor_open mdb_page_search:5445:7041 db 1 root page 1291 has flags 0x2 mdb_page_search_root:5342:7041 found leaf page 1291 for key [56617273] mdb_node_search:5091:7041 searching 5 keys in leaf page 1291 mdb_node_search:5135:7041 found leaf index 2 [5472616e73616374696f6e52656673], rc = 2 mdb_node_search:5135:7041 found leaf index 3 [5472616e73616374696f6e73], rc = 2 mdb_node_search:5135:7041 found leaf index 4 [56617273], rc = 0 mdb_page_search:5445:7041 db 4 root page 530 has flags 0x1 mdb_cursor_get:6103:7041 mdb_cursor_get mdb_cursor_first:6011:7041 mdb_cursor_first mdb_page_search:5445:7041 db 4 root page 530 has flags 0x1 mdb_page_search_root:5290:7041 branch page 530 has 3 keys mdb_page_search_root:5296:7041 found index 0 to page 535 mdb_cursor_push:5202:7041 pushing page 535 on db 4 cursor 0x7f4030000d00 mdb_page_search_root:5290:7041 branch page 535 has 68 keys mdb_page_search_root:5296:7041 found index 0 to page 35 mdb_cursor_push:5202:7041 pushing page 35 on db 4 cursor 0x7f4030000d00 mdb_page_search_root:5342:7041 found leaf page 35 for key [null] RM:b1f3f9b0(/tmp/data2) VarUUId:0000000000000000000000000000000000000000 [0 0 0 0 26 0 0 0 0 0 0 0 0 0 5 0 17 0 0 0 162 0 0 0 25 0 0 0 2 0 0 0 21 0 0 0 162 0 0 0 28 0 0 0 0 0 2 0 52 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 49 30 125 197 0 0 0 0 5 0 0 0 14 0 0 0 17 0 0 0 13 0 0 0 1 0 0 0 162 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 5 0 0 0 14 0 0 0 5 0 0 0 13 0 0 0 5 0 0 0 162 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] mdb_txn_renew:2749:7039 mdb_txn_renew mdb_txn_renew:2759:7039 renew txn 1862r 0x7f4034000a10 on mdbenv 0xd483c0, root page 417 mdb_cursor_open:7408:7039 mdb_cursor_open mdb_page_search:5445:7039 db 1 root page 417 has flags 0x2 mdb_page_search_root:5342:7039 found leaf page 417 for key [5472616e73616374696f6e73] mdb_node_search:5091:7039 searching 5 keys in leaf page 417 mdb_node_search:5135:7039 found leaf index 2 [5472616e73616374696f6e52656673], rc = 8448 mdb_node_search:5135:7039 found leaf index 3 [5472616e73616374696f6e73], rc = 0 mdb_page_search:5445:7039 db 4 root page 276 has flags 0x1 mdb_cursor_get:6103:7039 mdb_cursor_get mdb_cursor_first:6011:7039 mdb_cursor_first mdb_page_search:5445:7039 db 4 root page 276 has flags 0x1 mdb_page_search_root:5290:7039 branch page 276 has 2 keys mdb_page_search_root:5296:7039 found index 0 to page 710 mdb_cursor_push:5202:7039 pushing page 710 on db 4 cursor 0x7f4034000bd0 mdb_page_search_root:5290:7039 branch page 710 has 134 keys mdb_page_search_root:5296:7039 found index 0 to page 43 mdb_cursor_push:5202:7039 pushing page 43 on db 4 cursor 0x7f4034000bd0 mdb_page_search_root:5342:7039 found leaf page 43 for key [null] mdb_cursor_close:7493:7039 mdb_cursor_close mdb_txn_reset:2990:7039 mdb_txn_reset mdb_txn_end:2919:7039 mdb_txn_end mdb_txn_end:2931:7039 reset txn 1862r 0x7f4034000a10 on mdbenv 0xd483c0, root page 417 GoshawkDBConsistencyChecker 2016/03/26 22:24:37.802540 Shutting down iterator GoshawkDBConsistencyChecker 2016/03/26 22:24:37.802554 Err on finding first var in RM:311e7dc5(/tmp/data1): expected to find topology var, but found VarUUId:000000000000000000000000000000015b297cbd instead! ([0 0 0 0 30 0 0 0 0 0 0 0 2 0 3 0 189 124 41 91 1 0 0 0 0 2 0 0 2 0 0 0 9 0 0 0 162 0 0 0 17 0 0 0 47 0 0 0 57 0 0 0 55 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 91 41 124 189 0 0 0 0 4 0 0 0 1 0 4 0 3 0 0 0 0 0 0 0 13 0 0 0 162 0 0 0 21 0 0 0 42 0 0 0 21 0 0 0 2 0 0 0 17 0 0 0 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 91 41 124 189 0 0 0 0 0 1 2 3 4 0 0 0 0 0 0 0 0 0 2 0 12 0 0 0 1 0 1 0 197 125 30 49 1 0 0 0 17 0 0 0 11 0 0 0 176 249 243 177 1 0 0 0 13 0 0 0 11 0 0 0 189 124 41 91 0 0 0 0 9 0 0 0 11 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]) --hQiwHBbRI9kgIhsi--

1 0

Re: (ITS#8392) Opening multiple databases from the same process
by matthew＠wellquite.org 26 Mar '16

26 Mar '16

--rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Howard, Thanks for the quick reply. On Sat, Mar 26, 2016 at 06:44:29PM +0000, Howard Chu wrote: > Is this entire task read-only, nobody is modifying any of the DBs while > these readers are iterating thru the DBs? This entire process is read only, and indeed the transactions that contain cursors are marked RDONLY. No other process is running that accesses any of these databases. > You might consider compiling LMDB with MDB_DEBUG defined, enabling debug > output, and then watching the cursor activity. Of course, the act of writing > debug messages will impact thread scheduling, so it may not reveal what's > going on. Ok, I've done all that and got debug output going. I can still provoke the same problem easily. A log is attached. Ultimately, both cursors should start on a key 0000000000000000000000000000000000000000, but the second cursor/db discovers it actually starts on 0000000000000000000000000000000141d8872b. One problem is that the debug output gives no indication of which thread is which so it seems pretty tricky to separate out the different calls. Do you have any hints or tricks for doing this? Matthew --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=log GoshawkDBConsistencyChecker 2016/03/26 20:58:25.362121 [./consistencychecker /tmp/data1 /tmp/data2] GoshawkDBConsistencyChecker 2016/03/26 20:58:25.362201 ...loading from /tmp/data1 GoshawkDBConsistencyChecker 2016/03/26 20:58:25.362223 Starting disk server on /tmp/data1 mdb_env_open2:4175 opened database version 1, pagesize 4096 mdb_env_open2:4176 using meta page 0 mdb_env_open2:4177 depth: 1 mdb_env_open2:4178 entries: 5 mdb_env_open2:4179 branch pages: 0 mdb_env_open2:4180 leaf pages: 1 mdb_env_open2:4181 overflow pages: 0 mdb_env_open2:4182 root: 1192 mdb_env_open:4803 opened dbenv 0xd363c0 mdb_txn_begin:2850 begin txn 1785w 0xd37660 on mdbenv 0xd363c0, root page 1192 mdb_page_search:5426 db 1 root page 1192 has flags 0x2 mdb_page_search_root:5323 found leaf page 1192 for key [5472616e73616374696f6e52656673] mdb_node_search:5072 searching 5 keys in leaf page 1192 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 0 mdb_cursor_set:5980 ==> cursor placed on key [5472616e73616374696f6e52656673] mdb_page_search:5426 db 1 root page 1192 has flags 0x2 mdb_page_search_root:5323 found leaf page 1192 for key [56617273] mdb_node_search:5072 searching 5 keys in leaf page 1192 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 2 mdb_node_search:5116 found leaf index 3 [5472616e73616374696f6e73], rc = 2 mdb_node_search:5116 found leaf index 4 [56617273], rc = 0 mdb_cursor_set:5980 ==> cursor placed on key [56617273] mdb_page_search:5426 db 1 root page 1192 has flags 0x2 mdb_page_search_root:5323 found leaf page 1192 for key [5472616e73616374696f6e73] mdb_node_search:5072 searching 5 keys in leaf page 1192 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 8448 mdb_node_search:5116 found leaf index 3 [5472616e73616374696f6e73], rc = 0 mdb_cursor_set:5980 ==> cursor placed on key [5472616e73616374696f6e73] mdb_txn_end:2918 empty-commit txn 1785w 0xd37660 on mdbenv 0xd363c0, root page 1192 mdb_txn_begin:2850 begin txn 1784r 0x7f36e8000a10 on mdbenv 0xd363c0, root page 1192 mdb_txn_end:2918 abort txn 1784r 0x7f36e8000a10 on mdbenv 0xd363c0, root page 1192 mdb_txn_begin:2850 begin txn 1784r 0x7f36e8000a10 on mdbenv 0xd363c0, root page 1192 mdb_get:5556 ===> get db 3 key [0000000000000000000000000000000000000000] mdb_page_search:5426 db 1 root page 1192 has flags 0x2 mdb_page_search_root:5323 found leaf page 1192 for key [56617273] mdb_node_search:5072 searching 5 keys in leaf page 1192 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 2 mdb_node_search:5116 found leaf index 3 [5472616e73616374696f6e73], rc = 2 mdb_node_search:5116 found leaf index 4 [56617273], rc = 0 mdb_page_search:5426 db 3 root page 854 has flags 0x1 mdb_page_search:5426 db 3 root page 854 has flags 0x1 mdb_page_search_root:5271 branch page 854 has 2 keys mdb_page_search_root:5277 found index 0 to page 868 mdb_node_search:5072 searching 2 keys in branch page 854 mdb_node_search:5119 found branch index 1 [00000000000001f500000006000000016634c9ee -> 734], rc = -1 mdb_page_search_root:5295 following index 0 for key [0000000000000000000000000000000000000000] mdb_cursor_push:5183 pushing page 868 on db 3 cursor 0x7f36f0d5e6c0 mdb_page_search_root:5271 branch page 868 has 135 keys mdb_page_search_root:5277 found index 0 to page 96 mdb_node_search:5072 searching 135 keys in branch page 868 mdb_node_search:5119 found branch index 67 [00000000000000c600000006000000016634c9ee -> 65], rc = -50688 mdb_node_search:5119 found branch index 33 [000000000000005a00000006000000016634c9ee -> 61], rc = -23040 mdb_node_search:5119 found branch index 16 [000000000000001900000006000000016634c9ee -> 964], rc = -6400 mdb_node_search:5119 found branch index 8 [000000000000000f00000006000000016634c9ee -> 72], rc = -3840 mdb_node_search:5119 found branch index 4 [000000000000000500000006000000016634c9ee -> 124], rc = -1280 mdb_node_search:5119 found branch index 2 [000000000000000100000004000000016634c9ee -> 1021], rc = -256 mdb_node_search:5119 found branch index 1 [000000000000000000000006000000016634c9ee -> 869], rc = -1536 mdb_page_search_root:5295 following index 0 for key [0000000000000000000000000000000000000000] mdb_cursor_push:5183 pushing page 96 on db 3 cursor 0x7f36f0d5e6c0 mdb_page_search_root:5323 found leaf page 96 for key [0000000000000000000000000000000000000000] mdb_node_search:5072 searching 7 keys in leaf page 96 mdb_node_search:5116 found leaf index 3 [000000000000000000000000000000019f23085d], rc = -256 mdb_node_search:5116 found leaf index 1 [0000000000000000000000000000000141d8872b], rc = -256 mdb_node_search:5116 found leaf index 0 [0000000000000000000000000000000000000000], rc = 0 mdb_cursor_set:5980 ==> cursor placed on key [0000000000000000000000000000000000000000] mdb_get:5556 ===> get db 4 key [000000000000000100000000000000019f23085d] mdb_page_search:5426 db 1 root page 1192 has flags 0x2 mdb_page_search_root:5323 found leaf page 1192 for key [5472616e73616374696f6e73] mdb_node_search:5072 searching 5 keys in leaf page 1192 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 8448 mdb_node_search:5116 found leaf index 3 [5472616e73616374696f6e73], rc = 0 mdb_page_search:5426 db 4 root page 592 has flags 0x1 mdb_page_search:5426 db 4 root page 592 has flags 0x1 mdb_page_search_root:5271 branch page 592 has 128 keys mdb_page_search_root:5277 found index 0 to page 37 mdb_node_search:5072 searching 128 keys in branch page 592 mdb_node_search:5119 found branch index 64 [00000000000001fe000000000000000141d8872b -> 565], rc = -1 mdb_node_search:5119 found branch index 32 [00000000000000fe00000000000000019f23085d -> 461], rc = -64768 mdb_node_search:5119 found branch index 16 [000000000000007300000000000000016634c9ee -> 323], rc = -29184 mdb_node_search:5119 found branch index 8 [000000000000003f000000000000000141d8872b -> 20], rc = -15872 mdb_node_search:5119 found branch index 4 [000000000000001200000000000000019f23085d -> 448], rc = -4352 mdb_node_search:5119 found branch index 2 [000000000000000200000000000000019f23085d -> 141], rc = -256 mdb_node_search:5119 found branch index 1 [000000000000000100000000000000019f23085d -> 142], rc = 0 mdb_page_search_root:5295 following index 1 for key [000000000000000100000000000000019f23085d] mdb_cursor_push:5183 pushing page 142 on db 4 cursor 0x7f36f0d5e6c0 mdb_page_search_root:5323 found leaf page 142 for key [000000000000000100000000000000019f23085d] mdb_node_search:5072 searching 3 keys in leaf page 142 mdb_node_search:5116 found leaf index 1 [0000000000000002000000000000000141d8872b], rc = -256 mdb_node_search:5116 found leaf index 0 [000000000000000100000000000000019f23085d], rc = 0 mdb_cursor_set:5980 ==> cursor placed on key [000000000000000100000000000000019f23085d] mdb_txn_end:2918 reset txn 1784r 0x7f36e8000a10 on mdbenv 0xd363c0, root page 1192 GoshawkDBConsistencyChecker 2016/03/26 20:58:25.364770 ...loading from /tmp/data2 GoshawkDBConsistencyChecker 2016/03/26 20:58:25.364807 Starting disk server on /tmp/data2 mdb_env_open2:4175 opened database version 1, pagesize 4096 mdb_env_open2:4176 using meta page 1 mdb_env_open2:4177 depth: 1 mdb_env_open2:4178 entries: 5 mdb_env_open2:4179 branch pages: 0 mdb_env_open2:4180 leaf pages: 1 mdb_env_open2:4181 overflow pages: 0 mdb_env_open2:4182 root: 1239 mdb_env_open:4803 opened dbenv 0x7f36e00008c0 mdb_txn_begin:2850 begin txn 1858w 0x7f36e0001b80 on mdbenv 0x7f36e00008c0, root page 1239 mdb_page_search:5426 db 1 root page 1239 has flags 0x2 mdb_page_search_root:5323 found leaf page 1239 for key [5472616e73616374696f6e73] mdb_node_search:5072 searching 5 keys in leaf page 1239 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 8448 mdb_node_search:5116 found leaf index 3 [5472616e73616374696f6e73], rc = 0 mdb_cursor_set:5980 ==> cursor placed on key [5472616e73616374696f6e73] mdb_page_search:5426 db 1 root page 1239 has flags 0x2 mdb_page_search_root:5323 found leaf page 1239 for key [5472616e73616374696f6e52656673] mdb_node_search:5072 searching 5 keys in leaf page 1239 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 0 mdb_cursor_set:5980 ==> cursor placed on key [5472616e73616374696f6e52656673] mdb_page_search:5426 db 1 root page 1239 has flags 0x2 mdb_page_search_root:5323 found leaf page 1239 for key [56617273] mdb_node_search:5072 searching 5 keys in leaf page 1239 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 2 mdb_node_search:5116 found leaf index 3 [5472616e73616374696f6e73], rc = 2 mdb_node_search:5116 found leaf index 4 [56617273], rc = 0 mdb_cursor_set:5980 ==> cursor placed on key [56617273] mdb_txn_end:2918 empty-commit txn 1858w 0x7f36e0001b80 on mdbenv 0x7f36e00008c0, root page 1239 mdb_txn_begin:2850 begin txn 1857r 0x7f36e4000a10 on mdbenv 0x7f36e00008c0, root page 1239 mdb_txn_end:2918 abort txn 1857r 0x7f36e4000a10 on mdbenv 0x7f36e00008c0, root page 1239 mdb_txn_begin:2850 begin txn 1857r 0x7f36e4000a10 on mdbenv 0x7f36e00008c0, root page 1239 mdb_get:5556 ===> get db 4 key [0000000000000000000000000000000000000000] mdb_page_search:5426 db 1 root page 1239 has flags 0x2 mdb_page_search_root:5323 found leaf page 1239 for key [56617273] mdb_node_search:5072 searching 5 keys in leaf page 1239 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 2 mdb_node_search:5116 found leaf index 3 [5472616e73616374696f6e73], rc = 2 mdb_node_search:5116 found leaf index 4 [56617273], rc = 0 mdb_page_search:5426 db 4 root page 633 has flags 0x1 mdb_page_search:5426 db 4 root page 633 has flags 0x1 mdb_page_search_root:5271 branch page 633 has 2 keys mdb_page_search_root:5277 found index 0 to page 634 mdb_node_search:5072 searching 2 keys in branch page 633 mdb_node_search:5119 found branch index 1 [00000000000000f900000006000000016634c9ee -> 115], rc = -63744 mdb_page_search_root:5295 following index 0 for key [0000000000000000000000000000000000000000] mdb_cursor_push:5183 pushing page 634 on db 4 cursor 0x7f36f055d6c0 mdb_page_search_root:5271 branch page 634 has 68 keys mdb_page_search_root:5277 found index 0 to page 56 mdb_node_search:5072 searching 68 keys in branch page 634 mdb_node_search:5119 found branch index 34 [000000000000006100000006000000016634c9ee -> 562], rc = -24832 mdb_node_search:5119 found branch index 17 [000000000000001c00000006000000016634c9ee -> 18], rc = -7168 mdb_node_search:5119 found branch index 8 [000000000000000e00000006000000016634c9ee -> 160], rc = -3584 mdb_node_search:5119 found branch index 4 [000000000000000400000006000000016634c9ee -> 405], rc = -1024 mdb_node_search:5119 found branch index 2 [000000000000000100000004000000016634c9ee -> 489], rc = -256 mdb_node_search:5119 found branch index 1 [000000000000000000000006000000016634c9ee -> 636], rc = -1536 mdb_page_search_root:5295 following index 0 for key [0000000000000000000000000000000000000000] mdb_cursor_push:5183 pushing page 56 on db 4 cursor 0x7f36f055d6c0 mdb_page_search_root:5323 found leaf page 56 for key [0000000000000000000000000000000000000000] mdb_node_search:5072 searching 7 keys in leaf page 56 mdb_node_search:5116 found leaf index 3 [000000000000000000000000000000019f23085d], rc = -256 mdb_node_search:5116 found leaf index 1 [0000000000000000000000000000000141d8872b], rc = -256 mdb_node_search:5116 found leaf index 0 [0000000000000000000000000000000000000000], rc = 0 mdb_cursor_set:5980 ==> cursor placed on key [0000000000000000000000000000000000000000] mdb_get:5556 ===> get db 2 key [000000000000000100000000000000019f23085d] mdb_page_search:5426 db 1 root page 1239 has flags 0x2 mdb_page_search_root:5323 found leaf page 1239 for key [5472616e73616374696f6e73] mdb_node_search:5072 searching 5 keys in leaf page 1239 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 8448 mdb_node_search:5116 found leaf index 3 [5472616e73616374696f6e73], rc = 0 mdb_page_search:5426 db 2 root page 606 has flags 0x1 mdb_page_search:5426 db 2 root page 606 has flags 0x1 mdb_page_search_root:5271 branch page 606 has 128 keys mdb_page_search_root:5277 found index 0 to page 8 mdb_node_search:5072 searching 128 keys in branch page 606 mdb_node_search:5119 found branch index 64 [0000000000000219000000000000000141d8872b -> 414], rc = -2 mdb_node_search:5119 found branch index 32 [00000000000000fe00000000000000019f23085d -> 832], rc = -64768 mdb_node_search:5119 found branch index 16 [000000000000007400000000000000016634c9ee -> 85], rc = -29440 mdb_node_search:5119 found branch index 8 [000000000000003f000000000000000141d8872b -> 108], rc = -15872 mdb_node_search:5119 found branch index 4 [000000000000001200000000000000019f23085d -> 10], rc = -4352 mdb_node_search:5119 found branch index 2 [000000000000000200000000000000019f23085d -> 19], rc = -256 mdb_node_search:5119 found branch index 1 [000000000000000100000000000000019f23085d -> 33], rc = 0 mdb_page_search_root:5295 following index 1 for key [000000000000000100000000000000019f23085d] mdb_cursor_push:5183 pushing page 33 on db 2 cursor 0x7f36f055d6c0 mdb_page_search_root:5323 found leaf page 33 for key [000000000000000100000000000000019f23085d] mdb_node_search:5072 searching 3 keys in leaf page 33 mdb_node_search:5116 found leaf index 1 [0000000000000002000000000000000141d8872b], rc = -256 mdb_node_search:5116 found leaf index 0 [000000000000000100000000000000019f23085d], rc = 0 mdb_cursor_set:5980 ==> cursor placed on key [000000000000000100000000000000019f23085d] mdb_txn_end:2918 reset txn 1857r 0x7f36e4000a10 on mdbenv 0x7f36e00008c0, root page 1239 mdb_txn_renew:2750 renew txn 1857r 0x7f36e4000a10 on mdbenv 0x7f36e00008c0, root page 1239 mdb_page_search:5426 db 1 root page 1239 has flags 0x2 mdb_page_search_root:5323 found leaf page 1239 for key [56617273] mdb_node_search:5072 searching 5 keys in leaf page 1239 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 2 mdb_node_search:5116 found leaf index 3 [5472616e73616374696f6e73], rc = 2 mdb_node_search:5116 found leaf index 4 [56617273], rc = 0 mdb_page_search:5426 db 4 root page 633 has flags 0x1 mdb_page_search:5426 db 4 root page 633 has flags 0x1 mdb_page_search_root:5271 branch page 633 has 2 keys mdb_page_search_root:5277 found index 0 to page 634 mdb_cursor_push:5183 pushing page 634 on db 4 cursor 0x7f36e4000bd0 mdb_page_search_root:5271 branch page 634 has 68 keys mdb_page_search_root:5277 found index 0 to page 56 mdb_cursor_push:5183 pushing page 56 on db 4 cursor 0x7f36e4000bd0 mdb_page_search_root:5323 found leaf page 56 for key [null] RM:9f23085d(/tmp/data2) VarUUId:0000000000000000000000000000000000000000 [0 0 0 0 26 0 0 0 0 0 0 0 0 0 5 0 17 0 0 0 162 0 0 0 25 0 0 0 2 0 0 0 21 0 0 0 162 0 0 0 28 0 0 0 0 0 2 0 52 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 159 35 8 93 0 0 0 0 5 0 0 0 14 0 0 0 17 0 0 0 13 0 0 0 1 0 0 0 162 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 5 0 0 0 14 0 0 0 5 0 0 0 13 0 0 0 5 0 0 0 162 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] mdb_txn_renew:2750 renew txn 1784r 0x7f36e8000a10 on mdbenv 0xd363c0, root page 1192 mdb_page_search:5426 db 1 root page 1192 has flags 0x2 mdb_page_search_root:5323 found leaf page 1192 for key [5472616e73616374696f6e73] mdb_node_search:5072 searching 5 keys in leaf page 1192 mdb_node_search:5116 found leaf index 2 [5472616e73616374696f6e52656673], rc = 8448 mdb_node_search:5116 found leaf index 3 [5472616e73616374696f6e73], rc = 0 mdb_page_search:5426 db 4 root page 592 has flags 0x1 mdb_page_search:5426 db 4 root page 592 has flags 0x1 mdb_page_search_root:5271 branch page 592 has 128 keys mdb_page_search_root:5277 found index 0 to page 37 mdb_cursor_push:5183 pushing page 37 on db 4 cursor 0x7f36e8000bd0 mdb_page_search_root:5323 found leaf page 37 for key [null] mdb_txn_end:2918 reset txn 1784r 0x7f36e8000a10 on mdbenv 0xd363c0, root page 1192 GoshawkDBConsistencyChecker 2016/03/26 20:58:25.367498 Shutting down iterator GoshawkDBConsistencyChecker 2016/03/26 20:58:25.367507 Err on finding first var in RM:6634c9ee(/tmp/data1): expected to find topology var, but found VarUUId:0000000000000000000000000000000141d8872b instead! ([0 0 0 0 30 0 0 0 0 0 0 0 2 0 3 0 43 135 216 65 1 0 0 0 0 2 0 0 2 0 0 0 9 0 0 0 162 0 0 0 17 0 0 0 47 0 0 0 57 0 0 0 55 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 65 216 135 43 0 0 0 0 4 0 0 0 1 0 4 0 3 0 0 0 0 0 0 0 13 0 0 0 162 0 0 0 21 0 0 0 42 0 0 0 21 0 0 0 2 0 0 0 17 0 0 0 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 65 216 135 43 0 0 0 0 0 1 2 3 4 0 0 0 0 0 0 0 0 0 2 0 12 0 0 0 1 0 1 0 238 201 52 102 1 0 0 0 17 0 0 0 11 0 0 0 93 8 35 159 1 0 0 0 13 0 0 0 11 0 0 0 43 135 216 65 0 0 0 0 9 0 0 0 11 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]) --rwEMma7ioTxnRzrJ--

1 0

Re: (ITS#8392) Opening multiple databases from the same process
by hyc＠symas.com 26 Mar '16

26 Mar '16

matthew(a)wellquite.org wrote: > Full_Name: Matthew Sackman > Version: LMDB 0.9.18 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (109.149.185.170) > > > Linux koba 4.4.0-1-amd64 #1 SMP Debian 4.4.6-1 (2016-03-17) x86_64 GNU/Linux > LMDB 0.9.18 (compiled locally) > > I'm currently writing a program that iterates through multiple LMDB databases in > order to check differences between them. On each database I have one > long-running read-only txn with a cursor, and I'm walking through all the > databases at the same time. > > I'm seeing some very odd behaviour. For example, cursor.Get with FIRST is not > always returning the first item in the table (which I happen to know exactly > what it should be). The behaviour is non-deterministic - different runs produce > different results. > > I've searched through the docs and I can't find any statements regarding opening > multiple dbs from the same process. Is this supported? > > I'm writing this in Go, using my own bindings. I'm pretty certain that I'm doing > all the threading correctly and I certainly get this same issue regardless of > whether I'm using NOTLS or not (with my bindings, it shouldn't be necessary > because I'm locking go-routines to os-threads), plus these are the same bindings > that I've used throughout GoshawkDB and I've not come across this problem until > now. > > I can guarantee that each DB that I open will be opened in a different OS thread > and that no single OS thread will ever access different DBs. Is this entire task read-only, nobody is modifying any of the DBs while these readers are iterating thru the DBs? I've only used Go very briefly. I would be quite suspicious of that goroutine behavior but don't have any insight there. You might consider compiling LMDB with MDB_DEBUG defined, enabling debug output, and then watching the cursor activity. Of course, the act of writing debug messages will impact thread scheduling, so it may not reveal what's going on. -- -- 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

(ITS#8392) Opening multiple databases from the same process
by matthew＠wellquite.org 26 Mar '16

26 Mar '16

Full_Name: Matthew Sackman Version: LMDB 0.9.18 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.149.185.170) Linux koba 4.4.0-1-amd64 #1 SMP Debian 4.4.6-1 (2016-03-17) x86_64 GNU/Linux LMDB 0.9.18 (compiled locally) I'm currently writing a program that iterates through multiple LMDB databases in order to check differences between them. On each database I have one long-running read-only txn with a cursor, and I'm walking through all the databases at the same time. I'm seeing some very odd behaviour. For example, cursor.Get with FIRST is not always returning the first item in the table (which I happen to know exactly what it should be). The behaviour is non-deterministic - different runs produce different results. I've searched through the docs and I can't find any statements regarding opening multiple dbs from the same process. Is this supported? I'm writing this in Go, using my own bindings. I'm pretty certain that I'm doing all the threading correctly and I certainly get this same issue regardless of whether I'm using NOTLS or not (with my bindings, it shouldn't be necessary because I'm locking go-routines to os-threads), plus these are the same bindings that I've used throughout GoshawkDB and I've not come across this problem until now. I can guarantee that each DB that I open will be opened in a different OS thread and that no single OS thread will ever access different DBs.

1 0

(ITS#8391) peername string starts with "IP=" not "IP:"
by subbarao＠computer.org 25 Mar '16

25 Mar '16

Full_Name: Kartik Subbarao Version: 2.4.41 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.16.127.8) There is an error in the ACL section of the OpenLDAP Software 2.4 Administrator's guide: http://www.openldap.org/devel/admin/slapdconf2.html In the following line: by peername.regex=IP:10\..+ read Instead of "IP:", the correct syntax is "IP=". by peername.regex=IP=10\..+ read

1 0

(ITS#8390) New OpenLDAP mirror provided by Savoir-faire Linux
by clement.oudot＠savoirfairelinux.com 22 Mar '16

22 Mar '16

Full_Name: Clement Oudot Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.248.50.71) Hello, we just set up a new mirror in Canada (Quebec) for OpenLDAP: http://gpl.savoirfairelinux.net/pub/mirrors/openldap/ Could you please update MIRRORS file and download page (http://www.openldap.org/software/download/)? Thanks, Clement.

1 0

Re: (ITS#8389) ldapsearch
by quanah＠zimbra.com 16 Mar '16

16 Mar '16

--On Wednesday, March 16, 2016 4:13 PM +0000 baulin_ss(a)mail.ru wrote: > Full_Name: Baulin Sergey > Version: unknown > OS: Debian8.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.26.169.27) The ITS system is for reporting bugs with openldap, not asking how to write proper shell scripts. This ITS will be closed. -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8389) ldapsearch
by baulin_ss＠mail.ru 16 Mar '16

16 Mar '16

Full_Name: Baulin Sergey Version: unknown OS: Debian8.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.26.169.27) Hello. ldapsearch: @(#) $OpenLDAP: ldapsearch (Jan 17 2016 16:01:42) $ buildd@x86-csail-01:/build/openldap-EAKxYy/openldap-2.4.40+dfsg/debian/build/clients/tools (LDAP library: OpenLDAP 20440) I am running in bash: ldapsearch -H ldap://server -w password -b "DC=domain,DC=local" -s sub -D 'CN=user,DC=domain,DC=local' -x "(objectClass=user)" sn cn mail and it is working but if i am running in bash script: #!/bin/bash BINDDN='CN=user,DC=domain,%3=local' ldapsearch -H ldap://server -w password -b "DC=domain,DC=local" -s sub -D $BINDDN -x "(objectClass=user)" sn cn mail then: ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 525, v1772 Bash variable do not work only for key -D, for other keys bash variable is working

1 0

(ITS#8388) broken schema after replacing objectClass
by lessmian2＠o2.pl 16 Mar '16

16 Mar '16

Full_Name: Tomasz Le&#347;niewski Version: 2.4.44 OS: ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.128.131.1) accidentally i broke my openldap schema when i've changed one of objectClass definitions. For example i have two objectClasses and one is a parent for second: olcObjectClasses: {0}( 1.2.3.4 NAME 'foo' DESC '' SUP top AUXILIARY X-ORIGIN 'user defined' ) olcObjectClasses: {1}( 1.2.3.5 NAME 'bar' DESC '' SUP foo AUXILIARY X-ORIGIN 'user defined' ) I've changed definition of foo - i've delete this object and (my mistake) put it without any number at bottom of all classes: dn: cn=config changetype: modify delete: olcObjectClasses olcObjectClasses: {0} - add: olcObjectClasses olcObjectClasses: ( 1.2.3.4 NAME 'foo' DESC '' SUP top AUXILIARY X-ORIGIN 'user defined' ) So i have now class bar at top of schema and foo at bottom. After restart slapd won't start. Slapcat says: 56d4678f olcObjectClasses: value #5 olcObjectClasses: ObjectClass not found: "foo" 56d4678f config error processing cn=config: olcObjectClasses: ObjectClass not found: "foo" slapcat: bad configuration file! Should slapd allow to make something that could break schema? I thought that there are some constraints that not allow to remove objectClass which is parent for another class.

1 0

Re: (ITS#8384) LDAP Servers in Multi-master configuration locked up and unresponsive
by mhonek＠redhat.com 16 Mar '16

16 Mar '16

Here is the bug filed in Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1317000 On 03/15/2016 03:33 PM, Michael Ströder wrote: > mhonek(a)redhat.com wrote: > > this seems to be a RHEL/CentOS-specific issue. Please contact Red Hat Support. > > I think this ITS ticket may be closed. > > How about adding a link to Red Hat's issue tracker in this ticket? > > Ciao, Michael. > -- Matúš Honěk

1 0

Re: (ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by mkp37215＠gmail.com 15 Mar '16

15 Mar '16

On Mon, Mar 14, 2016 at 8:04 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > The Debian/Ubuntu maintainers are quite aware of the problems with using > GnuTLS, and maintain they cannot use OpenSSL due to licensing issues, > despite the fact every other major distribution uses OpenSSL (except RHEL, > which switched to MozNSS which resulted in much disaster, and is likely > going to switch back to OpenSSL). > > There is no reason you cannot use OpenSSL, regardless of what > Debian/Ubuntu's broken decisions are. > > --Quanah Quanah, thank you for your reply. However, I do not want to engage in a political discussion, particularly on the matter that is beyond my control. It is also out of topic, as the bug discussed here was in libldap code, and not in GnuTLS. I would like to again thank Howard for his work on this bug and coming up with a working fix very quickly. Unless any new issue related to this bug or the fix comes to light, I think we can consider the matter closed. Maciej Puzio

1 0

Re: (ITS#8384) LDAP Servers in Multi-master configuration locked up and unresponsive
by michael＠stroeder.com 15 Mar '16

15 Mar '16

mhonek(a)redhat.com wrote: > this seems to be a RHEL/CentOS-specific issue. Please contact Red Hat Support. > I think this ITS ticket may be closed. How about adding a link to Red Hat's issue tracker in this ticket? Ciao, Michael.

1 0

(ITS#8387) online olcDbConfig change fails with syncprov
by ryan＠openldap.org 15 Mar '16

15 Mar '16

Full_Name: Ryan Tandy Version: 2.4, master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan Forwarding from a Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816294 Configure a BDB or HDB database with syncprov: dn: olcDatabase={1}hdb,cn=config objectClass: olcHdbConfig olcDbDirectory: data olcSuffix: dc=example,dc=comD%D dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcSyncProvConfig perform some kind of modification to the database (so that a syncprov checkpoint is pending), and perform an online olcDbConfig change that reopens the database. dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcDbConfig olcDbConfig: set_cachesize 1 0 1 Reopening the database fails: 56e76e17 bdb(dc=example,dc=com): BDB4511 Error: closing the transaction region with active transactions 56e76e17 bdb_db_close: database "dc=example,dc=com": close failed: Invalid argument (22) and slapd crashes shortly after, when it tries to syncprov_checkpoint while the database is already gone. What appears to be happening is that "ctx" is different between bdb_reader_get and bdb_reader_flush in this case. During a normal slapd startup and shutdown: (gdb) thread apply all frame Thread 1 (Thread 0x7ffff7fed700 (LWP 21570)): #0 hdb_reader_get (op=0x7fffffffd8d0, env=0xa93fa0, txn=0x7fffffffd610) at cache.c:1666 1666 if ( !ctx ) { (gdb) p ctx $1 = (void *) 0x8b34a0 <ldap_int_main_thrctx> [ ... killall slapd ... ] (gdb) thread apply all frame Thread 1 (Thread 0x7ffff7fed700 (LWP 21570)): #0 hdb_reader_flush (env=0xa93fa0) at cache.c:1643 1643 if ( !ldap_pvt_thread_pool_getkey( ctx, env, &data, NULL ) ) { (gdb) p ctx $2 = (void *) 0x8b34a0 <ldap_int_main_thrctx> In this case, the readers are cleared correctly. Another startup, this time the hdb_db_close is triggered by performing an olcDbConfig change: (gdb) thread apply all frame Thread 1 (Thread 0x7ffff7fed700 (LWP 21624)): #0 hdb_reader_get (op=0x7fffffffd8d0, env=0xa93fa0, txn=0x7fffffffd610) at cache.c:1666 1666 if ( !ctx ) { (gd2929 p ctx $1 = (void *) 0x8b34a0 <ldap_int_main_thrctx> [ ... ldapmodify ... ] (gdb) thread apply all frame Thread 3 (Thread 0x7ffff362e700 (LWP 21633)): #0 hdb_reader_flush (env=0xa93fa0) at cache.c:1643 1643 if ( !ldap_pvt_thread_pool_getkey( ctx, env, &data, NULL ) ) { Thread 2 (Thread 0x7ffff3e2f700 (LWP 21631)): #0 0x00007ffff732d4d3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. Thread 1 (Thread 0x7ffff7fed700 (LWP 21624)): #0 0x00007ffff75f06dd in pthread_join (threadid=140737285125888, thread_return=0x0) at pthread_join.c:90 90 pthread_join.c: No such file or directory. (gdb) p ctx $2 = (void *) 0x7ffff362dbf0 This time we have a different ctx, so the readers are not cleared. This when we get to db->close there is still an active txn. The comment "free up any keys used by the main thread" seems to assume bdb_reader_flush will be called on the main thread only.

1 0

Re: (ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by quanah＠zimbra.com 15 Mar '16

15 Mar '16

--On Tuesday, March 15, 2016 1:34 AM +0000 mkp37215(a)gmail.com wrote: > --089e0139fc98189d9d052e0b902f > Content-Type: text/plain; charset=UTF-8 > > Howard, thank you very much for quickly fixing this issue. My tests show > that the replication is now working fine. > Regarding your recommendation of OpenSSL, that should rather go to > OpenLDAP package maintainers at Ubuntu and Debian. I use what they build > and the choice of the TLS library is not mine. The Debian/Ubuntu maintainers are quite aware of the problems with using GnuTLS, and maintain they cannot use OpenSSL due to licensing issues, despite the fact every other major distribution uses OpenSSL (except RHEL, which switched to MozNSS which resulted in much disaster, and is likely going to switch back to OpenSSL). There is no reason you cannot use OpenSSL, regardless of what Debian/Ubuntu's broken decisions are. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by mkp37215＠gmail.com 15 Mar '16

15 Mar '16

--089e0139fc98189d9d052e0b902f Content-Type: text/plain; charset=UTF-8 Howard, thank you very much for quickly fixing this issue. My tests show that the replication is now working fine. Regarding your recommendation of OpenSSL, that should rather go to OpenLDAP package maintainers at Ubuntu and Debian. I use what they build and the choice of the TLS library is not mine. --089e0139fc98189d9d052e0b902f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Howard, thank you very much for quickly fixing this i= ssue. My tests show that the replication is now working fine.<br></div>Rega= rding your recommendation of OpenSSL, that should rather go to OpenLDAP pac= kage maintainers at Ubuntu and Debian. I use what they build and the choice= of the TLS library is not mine.<br></div> --089e0139fc98189d9d052e0b902f--

1 0

(ITS#8386) Small LMDB Documentation patch
by philipp.storz＠bareos.com 14 Mar '16

14 Mar '16

Full_Name: Philipp Storz Version: LMDB 0.9.18 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.79.184.234) >From ede152281433d1e0bdc12741923c715360c4664a Mon Sep 17 00:00:00 2001 From: Philipp Storz <philipp.storz(a)bareos.com> Date: Mon, 14 Mar 2016 10:07:35 +0100 Subject: [PATCH] be a bit more precise that mdb_get retrieves data --- libraries/liblmdb/intro.doc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libraries/liblmdb/intro.doc b/libraries/liblmdb/intro.doc index 9fe9c22..2886c20 100644 --- a/libraries/liblmdb/intro.doc +++ b/libraries/liblmdb/intro.doc @@ -51,7 +51,7 @@ databases should only be opened once, by the first transaction in the process. After the first transaction completes, the database handles can freely be used by all subsequent transactions. -Within a transaction, #mdb_get() and #mdb_put(% c can store single +Within a transaction, #mdb_get() can retrieve and #mdb_put() can store single key/value pairs if that is all you need to do (but see \ref Cursors below if you want to do more). -- 2.6.2

1 0

Re: (ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by hyc＠symas.com 12 Mar '16

12 Mar '16

> Thanks for the report. Inspection shows that the issue only exists in > libldap's GnuTLS support. As always, the Project recommends you use OpenSSL. > > It also looks like only the ldo_tls_require_cert field is being used so we can > probably just copy that flag instead of keeping a pointer to the ldap options > structure. > Fixed now in git master. -- -- 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#8385) Use After Free of struct ldap_common in slap_client_connect
by hyc＠symas.com 12 Mar '16

12 Mar '16

mkp37215(a)gmail.com wrote: > Full_Name: Maciej Puzio > Version: 2.4.44 and current sources from git repo > OS: Ubuntu 15.10 amd64 > URL: > Submission from: (NULL) (129.112.109.41) > > > While configuring two servers in a dual-master setup I encountered an issue > causing replication failures, when replication is done on a TLS connection. In > this particular setup the issue manifested itself by replication retries > failing, even when the cause of the original failure no longer existed. For > example, let's consider that dual-master setup consists of servers A and B. If > server A was started before server B, its on-startup replication would fail (as > expected, since B is down). Server B would then be started and its replication > attempt would succeed (since A is already running). However A's subsequent > retries would fail, even though B was now accessible. If I then restarted server > A, its replication will succeed, but B will now lose connection to A and all B's > subsequent retries would fail. This issue has ~50% reproducibility, but if it > occurs once, then it would continue failing. On occasion both servers would > replicate fine, but obviously the whole situation was unacceptable on servers > being prepared for production use. > > I tested this issue thoroughly eliminating various hypotheses, and ended up > debugging OpenLDAP code and finding a bug causing the above behavior. In short, > on failure slap_client_connect deallocates LDAP object ld and objects pointed by > it, including ldap_common which contains ld_options. Pointer to ld_options is > held in sb->sb_tls_ctx and reused in subsequent slap_client_connect calls, at > this point referencing freed memory. > > This issue occurs in OpenLDAP newest stable version 2.4.44, as well as in > current source code from git repo (as of March 11, 2016), obtained from > git://git.openldap.org/openldap.git > Here, instead of freeing ld->ldc (struct ldap_common), I overwrite its contents > with a magic debug value 0xdeadbeef. I overwrite ldo_tls_require_cert, as an > incorrect value of this particular variable turned out to be the direct cause of > replication failures mentioned at the beginning (more about it later). However, > other fields of ldap_common could be used as well. > > File ldap-int.h is included to be able to examine contents of *ld, while the > declaration of struct tlsg_ctx has been copied verbatim from > libraries/libldap/tls_g.c, in order to examine the contents of > ld->ld_options.ldo_tls_ctx. I use GnuTLS library following Ubuntu build options. > But the issue in question is not GnuTLS-related, though it may cause different > symptoms with OpenSSL or Mozilla NSS (I did not test these options). Thanks for the report. Inspection shows that the issue only exists in libldap's GnuTLS support. As always, the Project recommends you use OpenSSL. It also looks like only the ldo_tls_require_cert field is being used so we can probably just copy that flag instead of keeping a pointer to the ldap options structure. -- -- 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

(ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by mkp37215＠gmail.com 12 Mar '16

12 Mar '16

Full_Name: Maciej Puzio Version: 2.4.44 and current sources from git repo OS: Ubuntu 15.10 amd64 URL: Submission from: (NULL) (129.112.109.41) While configuring two servers in a dual-master setup I encountered an issue causing replication failures, when replication is done on a TLS connection. In this particular setup the issue manifested itself by replication retries failing, even when the cause of the original failure no longer existed. For example, let's consider that dual-master setup consists of servers A and B. If server A was started before server B, its on-startup replication would fail (as expected, since B is down). Server B would then be started and its replication attempt would succeed (since A is already running). However A's subsequent retries would fail, even though B was now accessible. If I then restarted server A, its replication will succeed, but B will now lose connection to A and all B's subsequent retries would fail. This issue has ~50% reproducibility, but if it occurs once, then it would continue failing. On occasion both servers would replicate fine, but obviously the whole situation was unacceptable on servers being prepared for production use. I tested this issue thoroughly eliminating various hypotheses, and ended up debugging OpenLDAP code and finding a bug causing the above behavior. In short, on failure slap_client_connect deallocates LDAP object ld and objects pointed by it, including ldap_common which contains ld_options. Pointer to ld_options is held in sb->sb_tls_ctx and reused in subsequent slap_client_connect calls, at this point referencing freed memory. This issue occurs in OpenLDAP newest stable version 2.4.44, as well as in current source code from git repo (as of March 11, 2016), obtained from git://git.openldap.org/openldap.git In order to demonstrate that the issue is indeed use-after-free, I made the following debug modifications to the code. (The diffs are against the source code from git repo as of 2016/03/11) --- servers/slapd/config.c.orig 2016-03-11 14:52:14.000000000 -0600 +++ servers/slapd/config.c 2016-03-11 17:20:55.216170535 -0600 @@ -60,6 +60,26 @@ #define ARGS_STEP 512 + +/* DEBUG */ +#include <syslog.h> +#include <gnutls/gnutls.h> +#include "../../libraries/libldap/ldap-int.h" + +typedef struct tlsg_ctx { + struct ldapoptions *lo; + gnutls_certificate_credentials_t cred; + gnutls_dh_params_t dh_params; + unsigned long verify_depth; + int refcount; + gnutls_priority_t prios; +#ifdef LDAP_R_COMPILE + ldap_pvt_thread_mutex_t ref_mutex; +#endif +} tlsg_ctx; +/* END DEBUG */ + + /* * defaults for various global variables */ @@ -2001,9 +2021,11 @@ #ifdef HAVE_TLS if ( sb->sb_tls_do_init ) { + syslog(LOG_DEBUG, "DEBUG: slap_client_connect sb->sb_tls_do_init branch\n"); rc = bindconf_tls_set( sb, ld ); } else if ( sb->sb_tls_ctx ) { + syslog(LOG_DEBUG, "DEBUG: slap_client_connect sb->sb_tls_ctx branch\n"); rc = ldap_set_option( ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); } @@ -2015,6 +2037,7 @@ sb->sb_uri.bv_val, rc, 0 ); goto done; } + syslog(LOG_DEBUG, "DEBUG: slap_client_connect ldo_tls_require_cert=%X\n", ((tlsg_x*x*)ld->ld_options.ldo_tls_ctx)->lo->ldo_tls_require_cert); #endif --- libraries/libldap/unbind.c.orig 2016-03-11 14:52:14.000000000 -0600 +++ libraries/libldap/unbind.c 2016-03-11 15:49:18.603447766 -0600 @@ -27,6 +27,8 @@ #include "ldap-int.h" +#include <syslog.h> /* DEBUG */ + /* An Unbind Request looks like this: * * UnbindRequest ::= [APPLICATION 2] NULL @@ -208,6 +210,8 @@ #ifdef HAVE_TLS ldap_int_tls_destroy( &ld->ld_options ); + syslog(LOG_DEBUG, "DEBUG: ldap_ld_destroy\n"); + ld->ld_options.ldo_tls_require_cert = 0xdeadbeef; /* DEBUG */ #endif if ( ld->ld_options.ldo_sctrls != NULL ) { @@ -233,7 +237,7 @@ #ifndef NDEBUG LDAP_TRASH(ld); #endif - LDAP_FREE( (char *) ld->ldc ); + //LDAP_FREE( (char *) ld->ldc ); /* DEBUG */ LDAP_FREE( (char *) ld ); return( err ); Here, instead of freeing ld->ldc (struct ldap_common), I overwrite its contents with a magic debug value 0xdeadbeef. I overwrite ldo_tls_require_cert, as an incorrect value of this particular variable turned out to be the direct cause of replication failures mentioned at the beginning (more about it later). However, other fields of ldap_common could be used as well. File ldap-int.h is included to be able to examine contents of *ld, while the declaration of struct tlsg_ctx has been copied verbatim from libraries/libldap/tls_g.c, in order to examine the contents of ld->ld_options.ldo_tls_ctx. I use GnuTLS library following Ubuntu build options. But the issue in question is not GnuTLS-related, though it may cause different symptoms with OpenSSL or Mozilla NSS (I did not test these options). One would expect that the only effect of these modifications would be a mere memory leak, but in addition to that we see that the magic value gets logged. As you can see, the second replication attempts uses memory that, if executing non-debug code, would be already freed: The results are as follows (only one server started): Mar 11 17:42:21 srvA slapd[14360]: slapd starting Mar 11 17:42:21 srvA slapd[14360]: =>do_syncrepl rid=001 Mar 11 17:42:21 srvA slapd[14360]: DEBUG: slap_client_connect sb->sb_tls_do_init branch Mar 11 17:42:21 srvA slapd[14355]: ...done. Mar 11 17:42:21 srvA slapd[14360]: DEBUG: slap_client_connect ldo_tls_require_cert=0 Mar 11 17:42:21 srvA slapd[14360]: DEBUG: ldap_ld_destroy Mar 11 17:42:21 srvA slapd[14360]: do_syncrepl: rid=001 rc -1 retrying (9 retries left) Mar 11 17:42:51 srvA slapd[14360]: =>do_syncrepl rid=001 Mar 11 17:42:51 srvA slapd[14360]: DEBUG: slap_client_connect sb->sb_tls_ctx branch Mar 11 17:42:51 srvA slapd[14360]: DEBUG: slap_client_connect ldo_tls_require_cert=DEADBEEF Mar 11 17:42:51 srvA slapd[14360]: DEBUG: ldap_ld_destroy Mar 11 17:42:51 srvA slapd[14360]: do_syncrepl: rid=001 rc -1 retrying (8 retries left) When running unmodified non-debug code, on replication retry ld_options contains either (A) previous values, (B) zeros or (C) random values. Occasionally a segfault occurs (although I observed them only during debugging). Replication fails much more readily if, in addition to the issue discussed here, there is a TLS certificate problem. In this case connection tends to fail in tlsg_cert_verify, even if tls_reqcert is set to 'allow' or 'never'. This is because random value of ldo_tls_require_cert will cause the certificate to be checked regardless of tls_reqcert setting. If certificates are correct, the issue may well remain hidden, as TLS connection will be established regardless of whether A, B or C occurs. In this case an occasional segfault may be the only symptom. Of course, if by chance B occurs, certificate verification will be silently skipped and this may lead to a security problem. A quick and dirty fix is to comment out few lines in servers/slapd/config.c so that "rc = bindconf_tls_set( sb, ld )" is always executed, which avoids the reuse of sb->sb_tls_ctx. However, I think a better fix would involve changing the handling of ld->ldoptions and related objects. Given the complexity of interactions between various objects involved, and my limited familiarity with OpenLDAP design, I feel that I am not in position to propose a patch. For reference, OpenLDAP was build with this configuration: ./configure --prefix=/opt/openldap --enable-debug --enable-dynamic --enable-syslog --enable-local --enable-slapd --enable-crypt --enable-modules --enable-backends --enable-ndb=no --enable-shell=no --enable-perl=no --enable-sql=no --enable-wt=no --enable-overlays --with-tls=gnutls CPPFLAGS="-Wno-format-extra-args" The relevant parts of slapd.conf are [redacted to anonymize]: loglevel 1 serverID 001 moduleload syncprov TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSCACertificateFile /etc/ldap/ssl/ca.pem TLSCertificateFile /etc/ldap/ssl/srvA.pem TLSCertificateKeyFile /etc/ldap/ssl/srvA.key syncrepl rid=001 provider=ldaps://10.0.0.2 type=refreshAndPersist retry="30 10 300 +" searchbase="dc=test" attrs="*,+" bindmethod=simple binddn="cn=root,dc=test" credentials="plaintext-password" tls_reqcert=never keepalive="240:5:10" mirrormode TRUE overlay syncprov syncprov-checkpoint 10 1440 Test machine hardware: CPU: Intel Atom C2558 @ 2.40GHz Motherboard: Supermicro A1SRM-2558F NIC: Intel Corporation Ethernet Connection I354 (rev 03) Software used: OS: Ubuntu 15.10 Kernel: 4.2.0-30-generic #36-Ubuntu SMP x86_64 OpenLDAP: slapd 2.4.44 and slapd 2.X (from git repo) GnuTLS: 3.3.15-5ubuntu2 Please let me know if you need further information. Thank you. Maciej Puzio

1 0

Re: (ITS#8384) LDAP Servers in Multi-master configuration locked up and unresponsive
by hyc＠symas.com 11 Mar '16

11 Mar '16

mhonek(a)redhat.com wrote: > Hello, > > this seems to be a RHEL/CentOS-specific issue. Please contact Red Hat Support. > I think this ITS ticket may be closed. Sounds good, thanks. If it's not RHEL/CentOS-specific, we can re-open it but investigating would require updating from 2.4.39 to current. -- -- 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#8384) LDAP Servers in Multi-master configuration locked up and unresponsive
by mhonek＠redhat.com 11 Mar '16

11 Mar '16

Hello, this seems to be a RHEL/CentOS-specific issue. Please contact Red Hat Support. I think this ITS ticket may be closed. Regards. On 03/11/2016 04:01 PM, kevin4sullivan(a)gmail.com wrote: > Full_Name: Kevin Sullivan > Version: 2.4.39-8 > OS: RHEL 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (38.127.164.138) > > > Setup: > > I have two OpenLDAP servers running on separate hosts and replicating via delta > syncrepl in mirrormode. > > Problem: > > On rare occasions when one of my servers comes online, both servers will lock up > and be unresponsive. Any query to either server will time out. The servers will > stay in this state indefinitely. > > Workaround: > > Killing either of the servers will resolve this problem. > > Observations: > > - I don't know how to reproduce this reliably. > - Both servers have a thread that is stuck in a do_syncrep1() call. > - Netstat shows that each server has unacknowledged data in one of their > socket's receive queue. > > > GDB on host1: > > (gdb) info threads > 18 Thread 0x7f8b7b80d700 (LWP 31620) 0x00007f8ba7fa6f03 in epoll_wait () from > /lib64/libc.so.6 > 17 Thread 0x7f8b7b00c700 (LWP 31621) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 16 Thread 0x7f8b7a80b700 (LWP 31622) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 15 Thread 0x7f8b7a00a700 (LWP 31623) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 14 Thread 0x7f8b79809700 (LWP 31625) 0x00007f8ba846a54d in read () from > /lib64/libpthread.so.0 > 13 Thread 0x7f8b79008700 (LWP 31626) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 12 Thread 0x7f8b59ffd700 (LWP 25459) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 11 Thread 0x7f8b597fc700 (LWP 10195) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 10 Thread 0x7f8b70b37700 (LWP 28996) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 9 Thread 0x7f8b58ffb700 (LWP 8763) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 8 Thread 0x7f8b4bfff700 (LWP 28614) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 7 Thread 0x7f8b4b7fe700 (LWP 23367) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 6 Thread 0x7f8b4affd700 (LWP 13359) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 5 Thread 0x7f8b4a7fc700 (LWP 29064) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 4 Thread 0x7f8b49ffb700 (LWP 2184) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 3 Thread 0x7f8b497fa700 (LWP 31175) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 2 Thread 0x7f8b48ff9700 (LWP 2316) 0x00007f8ba846a054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > * 1 Thread 0x7f8baa8db700 (LWP 31615) 0x00007f8ba84640ad in pthread_join () > from /lib64/libpthread.so.0 > (gdb) bt > #0 0x00007f8ba84640ad in pthread_join () from /lib64/libpthread.so.0 > #1 0x00007f8baa93c969 in slapd_daemon () at > ../../%./servers/slapd/daemon.c:2929 > #2 0x00007f8baa927733 in main (argc=6, argv=<value optimized out>) at > ../../../servers/slapd/main.c:1012 > (gdb) thread 2 > [Switching to thread 2 (Thread 0x7f8b48ff9700 (LWP 2316))]#0 0x00007f8ba846a054 > in __lll_lock_wait (929 from /lib64/libpthread.so.0 > (gdb) bt > #0 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x00007f8ba8465388 in _L_lock_854 () from /lib64/libpthread.so.0 > #2 0x00007f8ba8465257 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x00007f8baa4b96a0 in tlsm_session_accept_or_connect > (session=0x7f8b2c104110, is_accept=<value optimized out>) at tls_m.c:2656 > #4 0x00007f8baa4b8787 in ldap_pvt_tls_accept (sb=0x7f8b2c104150, > ctx_arg=0x7f8bac6f8230) at tls2.c:425 > #5 0x00007f8baa943f23 in connection_read (ctx=0x7f8b48ff8b70, argv=0x2f) at > ../../../servers/slapd/connection.c:1372 > #6 connection_read_thread (ctx=0x7f8b48ff8b70, argv=0x2f) at > ../../../servers/slapd/connection.c:1284 > #7 0x00007f8baa490a98 in ldap_int_thread_pool_wrapper (xpool=0x7f8bac5c8fb0) at > ../../../libraries/libldap_r/tpool.c:688 > #8 0x00007f8ba8463851 in start_thread () from /lib64/libpthread.so.0 > #9 0x00007f8ba7fa690d in clone () from /lib64/libc.so.6 > (gdb) thread 14 > [Switching to thread 14 (Thread 0x7f8b79809700 (LWP 31625))]#0 > 0x00007f8ba846a54d in read () from /lib64/libpthread.so.0 > (gdb) bt > #0 0x00007f8ba846a54d in read () from /lib64/libpthread.so.0 > #1 0x00007f8baa278b1c in sb_debug_read (sbiod=0x7f8b681def80, > buf=0x7f8b6819c830, len=5) at ../../../libraries/liblber/sockbuf.c:829 > #2 0x00007f8baa4b9984 in tlsm_PR_Recv (fd=<value optimized out>, > buf=0x7f8b6819c830, len=5, flags=<value optimized out>, timeout=<value optimized > out>) at tls_m.c:3007 > #3 0x00007f8ba946c1ed in ?? () from /usr/lib64/libssl3.so > #4 0000007f8ba9467480 in ?? () from /usr/lib64/libssl3.so > #5 0x00007f8ba9469ed2 in ?? () from /usr/lib64/libssl3.so > #6 0x00007f8ba9470135 in ?? () from /usr/lib64/libssl3.so > #7 0x00007f8ba947196f in SSL_ForceHandshake () from /usr/lib64/libssl3o%o > #8 0x00007f8baa4b96a8 in tlsm_session_accept_or_connect > (session=0x7f8b681b0f20, is_accept=<value optimized out>) at tls_m.c:2658 > #9 0x00007f8baa4b82e2 in ldap_int_tls_connect (ld=0x7f8b681d9250, conn=<value > optimized out>) at tls2.c:362 > #10 0x00007f8baa4b857inin ldap_int_tls_start (ld=0x7f8b681d9250, > conn=0x7f8b681b0ba0, srv=<value optimized out>) at tls2.c:860 > #11 0x00007f8baa4b86ce in ldap_start_tls_s (ld=0x7f8b681d9250, serverctrls=0x0, > clientctrls=0x0) at tls2.c:1040 > #12 0x00007f8baa937ff6 in slap_client_connect (ldp=0x7f8bac6d35a8, > sb=0x7f8bac6d3380) at ../../../servers/slapd/config.c:2012 > #13 0x00007f8baa9ae3f5 in do_syncrep1 (ctx=<value optimized out>, > arg=0x7f8bac6cc430) at ../../../servers/slapd/syncrepl.c:613 > #14 do_syncrepl (ctx=<value optimized out>, arg=0x7f8bac6cc430) at > ../../../servers/slapd/syncrepl.c:1527 > #15 0x00007f8baa490a98 in ldap_int_thread_pool_wrapper (xpool=0x7f8bac5c8fb0) at > ../../../libraries/libldap_r/tpool.c:688 > #16 0x00007f8ba8463851 in start_thread () from /lib64/libpthread.so.0 > #17 0x00007f8ba7fa690d in clone () from /lib64/libc.so.6 > (gdb) thread 18 > [Switching to thread 18 (Thread 0x7f8b7b80d700 (LWP 31620))]#0 > 0x00007f8ba7fa6f03 in epoll_wait () from /lib64/libc.so.6 > (gdb) bt > #0 0x00007f8ba7fa6f03 in epoll_wait () from /lib64/libc.so.6 > #1 0x00007f8baa93d9e2 in slapd_daemon_task (ptr=<value optimized out>) at > ../../../servers/slapd/daemon.c:2536 > #2 0x00007f8ba8463851 in start_thread () from /lib64/libpthread.so.0 > #3 0x00007f8ba7fa690d in clone () from /lib64/libc.so.6 > > > GDB on host2: > > (gdb) info threads > 7 Thread 0x7f5c942d5700 (LWP 3869) 0x00007f5cc0797f03 in epoll_wait () from > /lib64/libc.so.6 > 6 Thread 0x7f5c93ad4700 (LWP 3870) 0x00007f5cc0c5b54d in read () from > /lib64/libpthread.so.0 > 5 Thread 0x7f5c932d3700 (LWP 3871) 0x00007f5cc0c5b054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 4 Thread 0x7f5c92ad2700 (LWP 3872) 0x00007f5cc0c5843c in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 3 Thread 0x7f5c922d1700 (LWP 3873) 0x00007f5cc0c5843c in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 2 Thread 0x7f5c91ad0700 (LWP 3874) 0x00007f5cc0c5843c in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > * 1 Thread 0x7f5cc30cc700 (LWP 3868) 0x00007f5cc0c550ad in pthread_join () from > /lib64/libpthread.so.0 > (gdb) bt > #0 0x00007f5cc0c550ad in pthread_join () from /lib64/libpthread.so.0 > #1 0x00007f5cc312d969 in slapd_daemon () at > ../../../servers/slapd/daemon.c:2929 > #2 0x00007f5cc3118733 in main (argc=6, argv=<value optimized out>) at > ../../../servers/slapd/main.c:1012 > (gdb) thread 2 > [Switching to thread 2 (Thread 0x7f5c91ad0700 (LWP 3874))]#0 0x00007f5cc0c5843c > in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > (gdb) bt > #0 0x00007f5cc0c5843c in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f5cc2c81af5 in ldap_int_thread_pool_wrapper (xpool=0x7f5cc3d18030) at > ../../../libraries/libldap_r/tpool.c:675 > #2 0x00007f5cc0c54851 in start_thread () from /lib64/libpthread.so.0 > #3 0x00007f5cc079790d in clone () from /lib64/libc.so.6 > (gdb) thread 5 > [Switching to thread 5 (Thread 0x7f5c932d3700 (LWP 3871))]#0 0x00007f5cc0c5b054 > in __lll_lock_wait () from /lib64/libpthread.so.0 > (gdb) bt > #0 0x00007f5cc0c5b054 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x00007f5cc0c56388 in _L_lock_854 () from /lib64/libpthread.so.0 > #2 0x00007f5cc0c56257 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x00007f5cc2caa6a0 in tlsm_session_accept_or_connect > (session=0x7f5c841165c0, is_accept=<value optimized out>) at tls_m.c:2656 > #4 0x00007f5cc2ca9787 in ldap_pvt_tls_accept (sb=0x7f5c800008c0, > ctx_arg=0x7f5cc3e3b240) at tls2.c:425 > #5 0x00007f5cc3134f23 in connection_read (ctx=0x7f5c932d2b70, argv=0x10) at > ../../../servers/slapd/connection.c:1372 > #6 connection_read_thread (ctx=0x7f5c932d2b70, argv=0x10) at > ../../../servers/slapd/connection.c:1284 > #7 0x00007f5cc2c81a98 in ldap_int_thread_pool_wrapper (xpool=0x7f5cc3d18030) at > ../../../libraries/libldap_r%tptpool.c:688 > #8 0x00007f5cc0c54851 in start_thread () from /lib64/libpthread.so.0 > #9 0x00007f5cc079790d in clone () from /lib64/libc.so.6 > (gdb) thread 6 > [Switching to thread 6 (Thread 0x7f5c93ad4700 (LWP 3870))]#0 0x00007f5cc0c5b54d > in read () from /lib64/libpthread.so.0 > (gdb) bt > #0 0x00007f5cc0c5b54d in read () from /lib64/libpthread.so.0 > #1 0x00007f5cc2a69b1c in sb_debug_read (sbiod=0x7f5c7c185e10, > buf=0x7f5c7c18a7f0, len=5) at ../../../libraries/liblber/sockbuf.c:829 > #2 0x00007f5cc2caa984 in tlsm_PR_Recv (fd=<value optimized out>, > buf=0x7f5c7c18a7f0, len=5, flags=<value optimized out>, timeout=<value optimized > out>) at tls_m.c:3007 > #3 0x00007f5cc1c5d1ed in ?? () from /usr/lib64/libssl3.so > #4 0x00007f5cc1c58480 in ?? () from /usr/lib64/libssl3.so > #5 0x00007f5cc1c5aed2 in ?? () from /usr/lib64/libssl3.so > #6 0x00007f5cc1c61135 in ?? () from /usr/lib64/libssl3.so > #7 0x00007f5cc1c6296f in SSL_ForceHandshake () from /usr/lib64/libssl3.so > #8 0x00007f5cc2caa6a8 in tlsm_session_accept_or_connect > (session=0x7f5c7c182100, is_accept=<value optimized out>) at tls_m.c:2658 > #9 0x00007f5cc2ca92e2 in ldap_int_tls_connect (ld=0x7f5c7c100910, conn=<value > optimized out>) at tls2.c:362 > #10 0x00007f5cc2ca9574 in ldap_int_tls_start (ld=0x7f5c7c100910, > conn=0x7f5c7c10a020, srv=<value optimized out>) at tls2.c:860 > #11 0x00007f5cc2ca96ce in ldap_start_tls_s (ld=0x7f5c7c100910, serverctrls=0x0, > clientctrls=0x0) at tls2.c:1040 > #12 0x00007f5cc3128ff6 in slap_client_connect (ldp=0x7f5cc3e22558, > sb=0x7f5cc3e22330) at ../../../servers/slapd/config.c:2012 > #13 0x00007f5cc319f3f5 in do_syncrep1 (ctx=<value optimized out>, > arg=0x7f5cc3e1f410) at ../../../servers/slapd/syncrepl.c:613 > #14 do_syncrepl (ctx=<value optimized out>, arg=0x7f5cc3e1f410) at > ../../../servers/slapd/syncrepl.c:1527 > #15 0x00007f5cc2c81a98 in ldap_int_thread_pool_wrapper (xpool=0x7f5cc3d18030) at > ../../../libraries/libldap_r/tpool.c:688 > #16 0x00007f5cc0c54851 in start_thread () from /lib64/libpthread.so.0 > #17 0x00007f5cc079790d in clone () from /lib64/libc.so.6 > (gdb) thread 7 > [Switching to thread 7 (Thread 0x7f5c942d5700 (LWP 3869))]#0 0x00007f5cc0797f03 > in epoll_wait () from /lib64/libc.so.6 > (gdb) bt > #0 0x00007f5cc0797f03 in epoll_wait () from /lib64/libc.so.6 > #1 0x00007f5cc312e9e2 in slapd_daemon_task (ptr=<value optimized out>) at > ../../../servers/slapd/daemon.c:2536 > #2 0x00007f5cc0c54851 in start_thread () from /lib64/libpthread.so.0 > #3 0x00007f5cc079790d in clone () from /lib64/libc.so.6 > > > Relevant configuration information (from host2): > > syncrepl rid=001 > provider=ldap://host1/ > type=refreshAndPersist > retry="10 +" > searchbase="dc=example,dc=com" > starttls=critical > tls_cacert=/etc/openldap/ssl-certs/cacert.pem > tls_cert=/etc/openldap/ssl-certs/host1.crt > tls_key=/etc/openldap/ssl-certs/host1.key > tls_reqcert=demand > bindmethod=sasl > saslmech=EXTERNAL > sizelimit=unlimited > keepalive="10:2:10" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > logbase="cn=accesslog" > syncdata=accesslog > > > Netstat of host1: > > [root@host1 ~]# netstat -anp | grep slapd > tcp 0 0 0.0.0.0:389 0.0.0.0:* > LISTEN 31615/slapd > tcp 56 0 192.168.1.1:389 192.168.1.2:57276 > ESTABLISHED 31615/slapd > tcp 0 0 192.168.1.1:45569 192.168.1.2:389 > ESTABLISHED 31615/slapd > unix 2 [ ] STREAM CONNECTED 45346152 31615/slapd > unix 2 [ ] DGRAM 45346144 31615/slapd > > Netstat of host2: > > [root@host2 ~]# netstat -anp | grep slapd > tcp 0 0 0.0.0.0:389 0.0.0.0:* > LISTEN 3868/slapd > tcp 56 0 192.168.1.2:389 192.168.1.1:45569 > ESTABLISHED 3868/slapd > tcp 0 0 192.168.1.2:57276 192.168.1.1:389 > ESTABLISHED 3868/slapd > unix 2 [ ] STREAM CONNECTED 19144 3868/slapd > unix [ ] DGRAM 19136 3868/slapd > > -- Matúš Honěk

1 0

(ITS#8384) LDAP Servers in Multi-master configuration locked up and unresponsive
by kevin4sullivan＠gmail.com 11 Mar '16

11 Mar '16

Full_Name: Kevin Sullivan Version: 2.4.39-8 OS: RHEL 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.127.164.138) Setup: I have two OpenLDAP servers running on separate hosts and replicating via delta syncrepl in mirrormode. Problem: On rare occasions when one of my servers comes online, both servers will lock up and be unresponsive. Any query to either server will time out. The servers will stay in this state indefinitely. Workaround: Killing either of the servers will resolve this problem. Observations: - I don't know how to reproduce this reliably. - Both servers have a thread that is stuck in a do_syncrep1() call. - Netstat shows that each server has unacknowledged data in one of their socket's receive queue. GDB on host1: (gdb) info threads 18 Thread 0x7f8b7b80d700 (LWP 31620) 0x00007f8ba7fa6f03 in epoll_wait () from /lib64/libc.so.6 17 Thread 0x7f8b7b00c700 (LWP 31621) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 16 Thread 0x7f8b7a80b700 (LWP 31622) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 15 Thread 0x7f8b7a00a700 (LWP 31623) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 14 Thread 0x7f8b79809700 (LWP 31625) 0x00007f8ba846a54d in read () from /lib64/libpthread.so.0 13 Thread 0x7f8b79008700 (LWP 31626) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 12 Thread 0x7f8b59ffd700 (LWP 25459) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 11 Thread 0x7f8b597fc700 (LWP 10195) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 10 Thread 0x7f8b70b37700 (LWP 28996) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 9 Thread 0x7f8b58ffb700 (LWP 8763) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 8 Thread 0x7f8b4bfff700 (LWP 28614) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 7 Thread 0x7f8b4b7fe700 (LWP 23367) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 6 Thread 0x7f8b4affd700 (LWP 13359) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 5 Thread 0x7f8b4a7fc700 (LWP 29064) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 4 Thread 0x7f8b49ffb700 (LWP 2184) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 3 Thread 0x7f8b497fa700 (LWP 31175) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 2 Thread 0x7f8b48ff9700 (LWP 2316) 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 * 1 Thread 0x7f8baa8db700 (LWP 31615) 0x00007f8ba84640ad in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f8ba84640ad in pthread_join () from /lib64/libpthread.so.0 #1 0x00007f8baa93c969 in slapd_daemon () at ../../%./servers/slapd/daemon.c:2929 #2 0x00007f8baa927733 in main (argc=6, argv=<value optimized out>) at ../../../servers/slapd/main.c:1012 (gdb) thread 2 [Switching to thread 2 (Thread 0x7f8b48ff9700 (LWP 2316))]#0 0x00007f8ba846a054 in __lll_lock_wait (929 from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f8ba846a054 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f8ba8465388 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x00007f8ba8465257 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f8baa4b96a0 in tlsm_session_accept_or_connect (session=0x7f8b2c104110, is_accept=<value optimized out>) at tls_m.c:2656 #4 0x00007f8baa4b8787 in ldap_pvt_tls_accept (sb=0x7f8b2c104150, ctx_arg=0x7f8bac6f8230) at tls2.c:425 #5 0x00007f8baa943f23 in connection_read (ctx=0x7f8b48ff8b70, argv=0x2f) at ../../../servers/slapd/connection.c:1372 #6 connection_read_thread (ctx=0x7f8b48ff8b70, argv=0x2f) at ../../../servers/slapd/connection.c:1284 #7 0x00007f8baa490a98 in ldap_int_thread_pool_wrapper (xpool=0x7f8bac5c8fb0) at ../../../libraries/libldap_r/tpool.c:688 #8 0x00007f8ba8463851 in start_thread () from /lib64/libpthread.so.0 #9 0x00007f8ba7fa690d in clone () from /lib64/libc.so.6 (gdb) thread 14 [Switching to thread 14 (Thread 0x7f8b79809700 (LWP 31625))]#0 0x00007f8ba846a54d in read () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f8ba846a54d in read () from /lib64/libpthread.so.0 #1 0x00007f8baa278b1c in sb_debug_read (sbiod=0x7f8b681def80, buf=0x7f8b6819c830, len=5) at ../../../libraries/liblber/sockbuf.c:829 #2 0x00007f8baa4b9984 in tlsm_PR_Recv (fd=<value optimized out>, buf=0x7f8b6819c830, len=5, flags=<value optimized out>, timeout=<value optimized out>) at tls_m.c:3007 #3 0x00007f8ba946c1ed in ?? () from /usr/lib64/libssl3.so #4 0000007f8ba9467480 in ?? () from /usr/lib64/libssl3.so #5 0x00007f8ba9469ed2 in ?? () from /usr/lib64/libssl3.so #6 0x00007f8ba9470135 in ?? () from /usr/lib64/libssl3.so #7 0x00007f8ba947196f in SSL_ForceHandshake () from /usr/lib64/libssl3o%o #8 0x00007f8baa4b96a8 in tlsm_session_accept_or_connect (session=0x7f8b681b0f20, is_accept=<value optimized out>) at tls_m.c:2658 #9 0x00007f8baa4b82e2 in ldap_int_tls_connect (ld=0x7f8b681d9250, conn=<value optimized out>) at tls2.c:362 #10 0x00007f8baa4b857inin ldap_int_tls_start (ld=0x7f8b681d9250, conn=0x7f8b681b0ba0, srv=<value optimized out>) at tls2.c:860 #11 0x00007f8baa4b86ce in ldap_start_tls_s (ld=0x7f8b681d9250, serverctrls=0x0, clientctrls=0x0) at tls2.c:1040 #12 0x00007f8baa937ff6 in slap_client_connect (ldp=0x7f8bac6d35a8, sb=0x7f8bac6d3380) at ../../../servers/slapd/config.c:2012 #13 0x00007f8baa9ae3f5 in do_syncrep1 (ctx=<value optimized out>, arg=0x7f8bac6cc430) at ../../../servers/slapd/syncrepl.c:613 #14 do_syncrepl (ctx=<value optimized out>, arg=0x7f8bac6cc430) at ../../../servers/slapd/syncrepl.c:1527 #15 0x00007f8baa490a98 in ldap_int_thread_pool_wrapper (xpool=0x7f8bac5c8fb0) at ../../../libraries/libldap_r/tpool.c:688 #16 0x00007f8ba8463851 in start_thread () from /lib64/libpthread.so.0 #17 0x00007f8ba7fa690d in clone () from /lib64/libc.so.6 (gdb) thread 18 [Switching to thread 18 (Thread 0x7f8b7b80d700 (LWP 31620))]#0 0x00007f8ba7fa6f03 in epoll_wait () from /lib64/libc.so.6 (gdb) bt #0 0x00007f8ba7fa6f03 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f8baa93d9e2 in slapd_daemon_task (ptr=<value optimized out>) at ../../../servers/slapd/daemon.c:2536 #2 0x00007f8ba8463851 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f8ba7fa690d in clone () from /lib64/libc.so.6 GDB on host2: (gdb) info threads 7 Thread 0x7f5c942d5700 (LWP 3869) 0x00007f5cc0797f03 in epoll_wait () from /lib64/libc.so.6 6 Thread 0x7f5c93ad4700 (LWP 3870) 0x00007f5cc0c5b54d in read () from /lib64/libpthread.so.0 5 Thread 0x7f5c932d3700 (LWP 3871) 0x00007f5cc0c5b054 in __lll_lock_wait () from /lib64/libpthread.so.0 4 Thread 0x7f5c92ad2700 (LWP 3872) 0x00007f5cc0c5843c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 0x7f5c922d1700 (LWP 3873) 0x00007f5cc0c5843c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2 Thread 0x7f5c91ad0700 (LWP 3874) 0x00007f5cc0c5843c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 Thread 0x7f5cc30cc700 (LWP 3868) 0x00007f5cc0c550ad in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f5cc0c550ad in pthread_join () from /lib64/libpthread.so.0 #1 0x00007f5cc312d969 in slapd_daemon () at ../../../servers/slapd/daemon.c:2929 #2 0x00007f5cc3118733 in main (argc=6, argv=<value optimized out>) at ../../../servers/slapd/main.c:1012 (gdb) thread 2 [Switching to thread 2 (Thread 0x7f5c91ad0700 (LWP 3874))]#0 0x00007f5cc0c5843c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f5cc0c5843c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f5cc2c81af5 in ldap_int_thread_pool_wrapper (xpool=0x7f5cc3d18030) at ../../../libraries/libldap_r/tpool.c:675 #2 0x00007f5cc0c54851 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f5cc079790d in clone () from /lib64/libc.so.6 (gdb) thread 5 [Switching to thread 5 (Thread 0x7f5c932d3700 (LWP 3871))]#0 0x00007f5cc0c5b054 in __lll_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f5cc0c5b054 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f5cc0c56388 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x00007f5cc0c56257 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f5cc2caa6a0 in tlsm_session_accept_or_connect (session=0x7f5c841165c0, is_accept=<value optimized out>) at tls_m.c:2656 #4 0x00007f5cc2ca9787 in ldap_pvt_tls_accept (sb=0x7f5c800008c0, ctx_arg=0x7f5cc3e3b240) at tls2.c:425 #5 0x00007f5cc3134f23 in connection_read (ctx=0x7f5c932d2b70, argv=0x10) at ../../../servers/slapd/connection.c:1372 #6 connection_read_thread (ctx=0x7f5c932d2b70, argv=0x10) at ../../../servers/slapd/connection.c:1284 #7 0x00007f5cc2c81a98 in ldap_int_thread_pool_wrapper (xpool=0x7f5cc3d18030) at ../../../libraries/libldap_r%tptpool.c:688 #8 0x00007f5cc0c54851 in start_thread () from /lib64/libpthread.so.0 #9 0x00007f5cc079790d in clone () from /lib64/libc.so.6 (gdb) thread 6 [Switching to thread 6 (Thread 0x7f5c93ad4700 (LWP 3870))]#0 0x00007f5cc0c5b54d in read () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f5cc0c5b54d in read () from /lib64/libpthread.so.0 #1 0x00007f5cc2a69b1c in sb_debug_read (sbiod=0x7f5c7c185e10, buf=0x7f5c7c18a7f0, len=5) at ../../../libraries/liblber/sockbuf.c:829 #2 0x00007f5cc2caa984 in tlsm_PR_Recv (fd=<value optimized out>, buf=0x7f5c7c18a7f0, len=5, flags=<value optimized out>, timeout=<value optimized out>) at tls_m.c:3007 #3 0x00007f5cc1c5d1ed in ?? () from /usr/lib64/libssl3.so #4 0x00007f5cc1c58480 in ?? () from /usr/lib64/libssl3.so #5 0x00007f5cc1c5aed2 in ?? () from /usr/lib64/libssl3.so #6 0x00007f5cc1c61135 in ?? () from /usr/lib64/libssl3.so #7 0x00007f5cc1c6296f in SSL_ForceHandshake () from /usr/lib64/libssl3.so #8 0x00007f5cc2caa6a8 in tlsm_session_accept_or_connect (session=0x7f5c7c182100, is_accept=<value optimized out>) at tls_m.c:2658 #9 0x00007f5cc2ca92e2 in ldap_int_tls_connect (ld=0x7f5c7c100910, conn=<value optimized out>) at tls2.c:362 #10 0x00007f5cc2ca9574 in ldap_int_tls_start (ld=0x7f5c7c100910, conn=0x7f5c7c10a020, srv=<value optimized out>) at tls2.c:860 #11 0x00007f5cc2ca96ce in ldap_start_tls_s (ld=0x7f5c7c100910, serverctrls=0x0, clientctrls=0x0) at tls2.c:1040 #12 0x00007f5cc3128ff6 in slap_client_connect (ldp=0x7f5cc3e22558, sb=0x7f5cc3e22330) at ../../../servers/slapd/config.c:2012 #13 0x00007f5cc319f3f5 in do_syncrep1 (ctx=<value optimized out>, arg=0x7f5cc3e1f410) at ../../../servers/slapd/syncrepl.c:613 #14 do_syncrepl (ctx=<value optimized out>, arg=0x7f5cc3e1f410) at ../../../servers/slapd/syncrepl.c:1527 #15 0x00007f5cc2c81a98 in ldap_int_thread_pool_wrapper (xpool=0x7f5cc3d18030) at ../../../libraries/libldap_r/tpool.c:688 #16 0x00007f5cc0c54851 in start_thread () from /lib64/libpthread.so.0 #17 0x00007f5cc079790d in clone () from /lib64/libc.so.6 (gdb) thread 7 [Switching to thread 7 (Thread 0x7f5c942d5700 (LWP 3869))]#0 0x00007f5cc0797f03 in epoll_wait () from /lib64/libc.so.6 (gdb) bt #0 0x00007f5cc0797f03 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f5cc312e9e2 in slapd_daemon_task (ptr=<value optimized out>) at ../../../servers/slapd/daemon.c:2536 #2 0x00007f5cc0c54851 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f5cc079790d in clone () from /lib64/libc.so.6 Relevant configuration information (from host2): syncrepl rid=001 provider=ldap://host1/ type=refreshAndPersist retry="10 +" searchbase="dc=example,dc=com" starttls=critical tls_cacert=/etc/openldap/ssl-certs/cacert.pem tls_cert=/etc/openldap/ssl-certs/host1.crt tls_key=/etc/openldap/ssl-certs/host1.key tls_reqcert=demand bindmethod=sasl saslmech=EXTERNAL sizelimit=unlimited keepalive="10:2:10" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase="cn=accesslog" syncdata=accesslog Netstat of host1: [root@host1 ~]# netstat -anp | grep slapd tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 31615/slapd tcp 56 0 192.168.1.1:389 192.168.1.2:57276 ESTABLISHED 31615/slapd tcp 0 0 192.168.1.1:45569 192.168.1.2:389 ESTABLISHED 31615/slapd unix 2 [ ] STREAM CONNECTED 45346152 31615/slapd unix 2 [ ] DGRAM 45346144 31615/slapd Netstat of host2: [root@host2 ~]# netstat -anp | grep slapd tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 3868/slapd tcp 56 0 192.168.1.2:389 192.168.1.1:45569 ESTABLISHED 3868/slapd tcp 0 0 192.168.1.2:57276 192.168.1.1:389 ESTABLISHED 3868/slapd unix 2 [ ] STREAM CONNECTED 19144 3868/slapd unix [ ] DGRAM 19136 3868/slapd

1 0

Re: (ITS#8382) Activation of idlcache leads to wrong ldapsearch results
by fdopheide＠iponweb.net 09 Mar '16

09 Mar '16

Hi, I am also adding the guide to replicate the error as plain text:=20 Step-by-step guide The following guide was created on an Ubuntu Linux V. 14.04.3 LTS, but = it should be executeable on an Debian based Linux operating systems. You = should be logged in as root user or adopt all commands with sudo. 1. Add hostname echo 'ldap-debug.example.com' > /etc/hostname && hostname `cat = /etc/hostname` && hostname echo '52.49.174.211 ldap-debug.example.com ldap-debug' >> /etc/hosts 2. Download latest Sources wget = http://www.openldap.org/software/download/OpenLDAP/openldap-release/openld= ap-2.4.44.tgz 3. Validate Sources(compare md5 provided on website with generated md5 = hash) md5sum openldap-2.4.44.tgz 4. Make archive executable and extract sources and change into = extracted directory chmod +x openldap-2.4.44.tgz && tar xzf openldap-2.4.44.tgz && cd = openldap-2.4.44 5. Fullfil most important software requirements (Dependencies) apt-get update apt-get install libdb-dev apt-get install openssl apt-get install gnutls-bin apt-get install gcc apt-get install make 6. Run configure with default settings and add a target dir only ./configure --prefix=3D/usr/local/openldap 7. Run make and install sources to target directory make depend make make test make install 8. Stop the daemon, because slapd was already started by make. pkill slapd 9. Edit main config file in /usr/local/openldap/etc/openldap/slapd.conf = and add the following lines: include /usr/local/openldap/etc/openldap/schema/core.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args modulepath /usr/lib/ldap moduleload back_hdb backend hdb database hdb suffix "dc=3Dexample,dc=3Dcom" rootdn "cn=3DManager,dc=3Dexample,dc=3Dcom" rootpw secret directory /var/lib/ldap index objectClass eq 10. Call slappasswd and set rootpw to secret slappasswd 11. Create data directory for hdb files mkdir /var/lib/ldap 12. We will add a symbolic link to ease slapd commands ln -s /usr/local/openldap/libexec/slapd /usr/local/bin/slapd 13. Add the path to OpenLDAP bin and sbin dirs and activate the new path echo "export = PATH=3D\$PATH:/usr/local/openldap/bin/:/usr/local/openldap/sbin/" >> = /root/.bashrc && source /root/.bashrc 14. Start the slapd daemon with -f flag for location of the config file slapd -f /usr/local/openldap/etc/openldap/slapd.conf 15. Create initial DIT file with an editor of your choice, i.e. vi = /root/create_dit.ldif and copy paste the following lines into this file. dn: dc=3Dexample,dc=3Dcom changetype: add objectClass: dcObject objectClass: organization objectClass: top dc: example o: example.com =20 dn: ou=3DProjects,dc=3Dexample,dc=3Dcom changetype: add ou: Projects objectClass: organizationalUnit =20 dn: ou=3DTrash,dc=3Dexample,dc=3Dcom changetype: add ou: Trash objectClass: organizationalUnit =20 dn: ou=3Dtest1,ou=3DProjects,dc=3Dexample,dc=3Dcom changetype: add ou: test1 objectClass: organizationalUnit =20 dn: ou=3Dtest2,ou=3Dtest1,ou=3DProjects,dc=3Dexample,dc=3Dcom changetype: add ou: test2 objectClass: organizationalUnit 16. Add the initial DIT ldapadd -H 'ldap://localhost' -D 'cn=3DManager,dc=3Dexample,dc=3Dcom' = -w secret -f /root/create_dit.ldif 17. Execute modrdn and assign directory Trash as a new superior of test1 = directory ldapmodrdn -x -w secret -D "cn=3DManager,dc=3Dexample,dc=3Dcom" -s = "ou=3DTrash,dc=3Dexample,dc=3Dcom" -r = "ou=3Dtest1,ou=3DProjects,dc=3Dexample,dc=3Dcom" "ou=3Dtest1" 18. Execute following ldapsearch and save the result somewhere for i in {,{,{,ou=3Dtest2\,}ou=3Dtest1\,}ou=3DTrash\,}dc=3Dexample,dc=3D= com; do echo -e "\n=3D=3D=3D=3D=3D> basedn: $i <=3D=3D=3D=3D=3D\n"; = ldapsearch -LLL -s 'sub' -H 'ldap://localhost:389' -D = 'cn=3DManager,dc=3Dexample,dc=3Dcom' -w secret -b "$i" '(ou=3Dtest*)' = dn; done Result: =3D=3D=3D=3D=3D> basedn: dc=3Dexample,dc=3Dcom <=3D=3D=3D=3D=3D dn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom =3D=3D=3D=3D=3D> basedn: ou=3DTrash,dc=3Dexample,dc=3Dcom <=3D=3D=3D=3D= =3D dn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom =3D=3D=3D=3D=3D> basedn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom = <=3D=3D=3D=3D=3D dn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom =3D=3D=3D=3D=3D> basedn: = ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom <=3D=3D=3D=3D=3D dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom 19. We see until here everything is working as expected, but now we will = enable cache and idlcache as recommended in OpenLDAP docs and = Performance Guides and problems will appear soon. echo -e "cachesize\t10000\nidlcachesize\t30000" >> = /usr/local/openldap/etc/openldap/slapd.conf 20. Remove existing DIT ldapdelete -H 'ldap://localhost' -D 'cn=3DManager,dc=3Dexample,dc=3Dco= m' -w secret -r "dc=3Dexample,dc=3Dcom" -v 21. Restart daemon and recreate initial DIT pkill slapd slapd -f /usr/local/openldap/etc/openldap/slapd.conf ldapadd -H 'ldap://localhost' -D 'cn=3DManager,dc=3Dexample,dc=3Dcom' = -w secret -f /root/create_dit.ldif 22. Execute modrdn ldapmodrdn -x -w secret -D "cn=3DManager,dc=3Dexample,dc=3Dcom" -s = "ou=3DTrash,dc=3Dexample,dc=3Dcom" -r = "ou=3Dtest1,ou=3DProjects,dc=3Dexample,dc=3Dcom" "ou=3Dtest1" 23. Check result again with ldapsearch for i in {,{,{,ou=3Dtest2\,}ou=3Dtest1\,}ou=3DTrash\,}dc=3Dexample,dc=3D= com; do echo -e "\n=3D=3D=3D=3D=3D> basedn: $i <=3D=3D=3D=3D=3D\n"; = ldapsearch -LLL -s 'sub' -H 'ldap://localhost:389' -D = 'cn=3DManager,dc=3Dexample,dc=3Dcom' -w secret -b "$i" '(ou=3Dtest*)' = dn; done Result: =3D=3D=3D=3D=3D> basedn: dc=3Dexample,dc=3Dcom <=3D=3D=3D=3D=3D dn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom =3D=3D=3D=3D=3D> basedn: ou=3DTrash,dc=3Dexample,dc=3Dcom <=3D=3D=3D=3D= =3D dn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom =3D=3D=3D=3D=3D> basedn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom = <=3D=3D=3D=3D=3D dn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom =3D=3D=3D=3D=3D> basedn: = ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom <=3D=3D=3D=3D=3D dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom 24. Once again the result was fine and as expected. Keep in mind cache = and idlcache were empty as we've restarted the daemon. Now we are = performing same actions again while we have cached results. 25. Remove directories in ou =E2=80=9ETrash=E2=80=9C ldapdelete -w secret -D "cn=3DManager,dc=3Dexample,dc=3Dcom" -r = "ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom" 26. Add directories to ou =E2=80=9EProjects=E2=80=9C again ldapmodify -D "cn=3DManager,dc=3Dexample,dc=3Dcom" -W Type in password Enter LDAP Password: Copy paste following ldif and be sure emtpy lines are copied, too! dn: ou=3Dtest1,ou=3DProjects,dc=3Dexample,dc=3Dcom changetype: add objectClass: organizationalUnit =20 dn: ou=3Dtest2,ou=3Dtest1,ou=3DProjects,dc=3Dexample,dc=3Dcom changetype: add objectClass: organizationalUnit 27. Now we have same DIT structure again and can rerun modrdn command ldapmodrdn -x -w secret -D "cn=3DManager,dc=3Dexample,dc=3Dcom" -s = "ou=3DTrash,dc=3Dexample,dc=3Dcom" -r = "ou=3Dtest1,ou=3DProjects,dc=3Dexample,dc=3Dcom" "ou=3Dtest1" 28. If we now check result with ldapsearch again the idlcache error will = appear for i in {,{,{,ou=3Dtest2\,}ou=3Dtest1\,}ou=3DTrash\,}dc=3Dexample,dc=3D= com; do echo -e "\n=3D=3D=3D=3D=3D> basedn: $i <=3D=3D=3D=3D=3D\n"; = ldapsearch -LLL -s 'sub' -H 'ldap://localhost:389' -D = 'cn=3DManager,dc=3Dexample,dc=3Dcom' -w secret -b "$i" '(ou=3Dtest*)' = dn; done Result: =3D=3D=3D=3D=3D> basedn: dc=3Dexample,dc=3Dcom <=3D=3D=3D=3D=3D dn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom =3D=3D=3D=3D=3D> basedn: ou=3DTrash,dc=3Dexample,dc=3Dcom <=3D=3D=3D=3D= =3D dn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom =3D=3D=3D=3D=3D> basedn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom = <=3D=3D=3D=3D=3D dn: ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom =3D=3D=3D=3D=3D> basedn: = ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom <=3D=3D=3D=3D=3D dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3Dcom 29. The search result of basedn: ou=3DTrash,dc=3Dexample,dc=3Dcom is = wrong! The line of dn: ou=3Dtest2,ou=3Dtest1,ou=3DTrash,dc=3Dexample,dc=3D= com is missing within the resultset. 30. After a restart of the daemon the missing line will appear again. = Actually the one and only solution is to switch of idlcachesize and set = it explicitely to "0" > Am 07.03.2016 um 11:45 schrieb fdopheide(a)iponweb.net: >=20 > Full_Name: Frank Dopheide > Version: slapd 2.4.44 (Mar 3 2016 10:27:05) > OS: Ubuntu 14.04.3 LTS > URL: http://52.48.8.167/idlcache_error.pdf > Submission from: (NULL) (87.139.29.59) >=20 >=20 > Good morning Gentlemen, >=20 > we've found a quite serious bug in slapd 2.4.44 on an Ubuntu 14.04.3 = LTS server. > As soon as we enable the idlcache the ldapsearch results will be wrong = after > moddn and modrdn commands. First result after idlcachesize activation = is still > correct as the cache is still empty and the daemon reads from db, but = as soon as > it starts reading from idlcache the latest modifications are missing = until slapd > will be restarted! >=20 > We've created a small howto to replicatehe e error. The howto is = available via > http: http://52.48.8.167/idlcache_error.pdf >=20 > Please let us now if you require any additional information! >=20 > Thx, > Frank >=20 >=20 >=20

1 0

(ITS#8383) msys build error "portable.h:1116:19: error: two or more data types in declaration specifiers"
by fixed-term.Asal.Mirzaieva＠boschrexroth.de 08 Mar '16

08 Mar '16

Full_Name: Asal Mirzaieva Version: 2.4.44 OS: Windows 7 URL: http://paste.ubuntu.com/15326640/, http://paste.ubuntu.com/15326646/, http://paste.ubuntu.com/15326655/ Submission from: (NULL) (194.39.218.10) When building openldap on windows, using msys and mingw (mingw32 v4.9.3) the following error appears: In file included from base64.c:38:0:../../include/portable.h:1116:19: error: two or more data types in declaration specifiers #define socklen_t int Steps to reproduce the bug: 1. Install Mingw32 with mingw-get-setup.exe. 2. Launch msys.bat in msys folder to open msys console. 3. Download and install Spencer's regex in /usr/local 4. Download openldap-2.4.44 5. Unzip and untar the openldap and go to the openldap-2.4.44's directory 6. Run configure as follows ./configure CFLAGS="-I/usr/local/include/rxspencer" LDFLAGS=2-2-L/usr/local/lib" LIBS="-static -lrxspencer" --enable-static --disable-shared --disable-slapd --disable-bdb --disable-hdb 7. Run make depend 8. Run make 9. Get the error, that was described above. I haven't tried to reproduce this bug with other PCs/OS versions/MinGW versions. Workaround: after commenting the line 1116 in include/portable.h the error was gone and I was able to successfully build and use openldap. Well, "successfully" means, I could link it statically and run ldap_initialize(), but not ldap_sals_bind(), because I haven't installed SASL.

1 0

(ITS#8382) Activation of idlcache leads to wrong ldapsearch results
by fdopheide＠iponweb.net 07 Mar '16

07 Mar '16

Full_Name: Frank Dopheide Version: slapd 2.4.44 (Mar 3 2016 10:27:05) OS: Ubuntu 14.04.3 LTS URL: http://52.48.8.167/idlcache_error.pdf Submission from: (NULL) (87.139.29.59) Good morning Gentlemen, we've found a quite serious bug in slapd 2.4.44 on an Ubuntu 14.04.3 LTS server. As soon as we enable the idlcache the ldapsearch results will be wrong after moddn and modrdn commands. First result after idlcachesize activation is still correct as the cache is still empty and the daemon reads from db, but as soon as it starts reading from idlcache the latest modifications are missing until slapd will be restarted! We've created a small howto to replicatehe e error. The howto is available via http: http://52.48.8.167/idlcache_error.pdf Please let us now if you require any additional information! Thx, Frank

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs