openldap-bugs September 2012

openldap-bugs@openldap.org

29 participants
107 discussions

(ITS#7387) submit a contribution
by philippe.eychart＠mail.pf 13 Sep '12

13 Sep '12

Full_Name: Philippe EYCHART Version: 2 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.70.54) My work is fully described and available here: http://homepage.gna.org/ldapcppei/miniHowto.en.html Regards. PE

1 0

Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by marco＠schirrmeister.net 13 Sep '12

13 Sep '12

--Apple-Mail=_D316E30E-F1E5-480E-A47A-F4610B0C33C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 12, 2012, at 7:49 PM, hyc(a)symas.com wrote: > Frank.Swasey(a)uvm.edu wrote: >> Full_Name: Francis Swasey >> Version: 2.4.32 >> OS: RHEL6.3 64-bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (132.198.21.181) >>=20 >>=20 >> In exploring converting to back_mdb, I have discovered a problem = which results >> in the following symptoms: >=20 > Thanks for the report, fixed now in git master. I saw it is also merged into the RE24 branch. I tried today the latest commit from the RE24 branch and I did not see = the error anymore in the slapadd tool. Where I noticed the No space left = on device error before. But I'm seeing it now when I run the slapindex. Unfortunately I can't reproduce it with a test dataset that I created. Probably because I have not enough attributes that I could add to index = like on the real server. If I run slapindex a second time, again error. If I run slapindex a third time, no error. The data.mdb grew a little bit during the slapindex runs. =46rom about 710MB to 1,2GB. If I remove a few index options, slapindex runs through without a = problem. The output on the test server looks like below. [root@ds71 ~]# slapadd2.4 -b dc=3Dogilvy,dc=3Dcom -l all_slapcat.ldif=20 _#################### 100.00% eta none elapsed 05m26s spd = 596.0 k/s=20 Closing DB... [root@ds71 ~]#=20 [root@ds71 ~]# slapindex2.4=20 5051fea8 =3D> mdb_tool_entry_reindex: txn_commit failed: No space left = on device (28) [root@ds71 ~]#=20 [root@ds71 ~]# slapindex2.4=20 50520b10 =3D> mdb_tool_entry_reindex: txn_commit failed: No space left = on device (28) [root@ds71 ~]#=20 [root@ds71 ~]# slapindex2.4=20 [root@ds71 ~]#=20 Since you wrote ENOSPC can only be happen in 2 places, I thought it's = still related somehow. I'm a little bit clueless right now what else I can provide. If there is something that I can provide, then let me know please and I = try to provide it. -- Marco --Apple-Mail=_D316E30E-F1E5-480E-A47A-F4610B0C33C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br><div><div>On Sep 12, 2012, at 7:49 PM, <a = href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a> wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = font-family: Helvetica; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: = none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><a = href=3D"mailto:Frank.Swasey@uvm.edu">Frank.Swasey(a)uvm.edu</a><span = class=3D"Apple-converted-space"> </span>wrote:<br><blockquote = type=3D"cite">Full_Name: Francis Swasey<br></blockquote><blockquote = type=3D"cite">Version: 2.4.32<br></blockquote><blockquote = type=3D"cite">OS: RHEL6.3 64-bit<br></blockquote><blockquote = type=3D"cite">URL:<span class=3D"Apple-converted-space"> </span><a = href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/= </a><br></blockquote><blockquote type=3D"cite">Submission from: (NULL) = (132.198.21.181)<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">In exploring = converting to back_mdb, I have discovered a problem which = results<br></blockquote><blockquote type=3D"cite">in the following = symptoms:<br></blockquote><br>Thanks for the report, fixed now in git = master.</span></blockquote></div><br><div>I saw it is also merged into = the RE24 branch.</div><div><br></div><div>I tried today the latest = commit from the RE24 branch and I did not see the error anymore in the = slapadd tool. Where I noticed the No space left on device = error before.</div><div>But I'm seeing it now when I run the = slapindex.</div><div><br></div><div>Unfortunately I can't reproduce it = with a test dataset that I created.</div><div>Probably because I have = not enough attributes that I could add to index like on the real = server.</div><div><br></div><div>If I run slapindex a second time, again = error.</div><div>If I run slapindex a third time, no = error.</div><div><br></div><div>The data.mdb grew a little bit during = the slapindex runs.</div><div>=46rom about 710MB to = 1,2GB.</div><div><br></div><div>If I remove a few index options, = slapindex runs through without a problem.</div><div><br></div><div>The = output on the test server looks like below.</div><div><div>[root@ds71 = ~]# slapadd2.4 -b dc=3Dogilvy,dc=3Dcom -l = all_slapcat.ldif </div><div>_#################### 100.00% eta =   none elapsed          05m26s spd 596.0 = k/s </div><div>Closing DB...</div><div>[root@ds71 = ~]# </div><div>[root@ds71 ~]# slapindex2.4 </div><div>5051fea8 = =3D> mdb_tool_entry_reindex: txn_commit failed: No space left on = device (28)</div><div>[root@ds71 ~]# </div><div>[root@ds71 ~]# = slapindex2.4 </div><div>50520b10 =3D> mdb_tool_entry_reindex: = txn_commit failed: No space left on device (28)</div><div>[root@ds71 = ~]# </div><div>[root@ds71 ~]# = slapindex2.4 </div><div>[root@ds71 = ~]# </div></div><div><br></div><div><br></div><div>Since you wrote = ENOSPC can only be happen in 2 places, I thought it's still related = somehow.</div><div>I'm a little bit clueless right now what else I can = provide.</div><div><br></div><div>If there is something that I can = provide, then let me know please and I try to provide = it.</div><div><br></div><div><br></div><div>--</div><div>Marco</div><div><= br></div><div><br></div></body></html>= --Apple-Mail=_D316E30E-F1E5-480E-A47A-F4610B0C33C6--

1 0

(ITS#7386) back-mdb slapindex grows DB without bound
by hyc＠OpenLDAP.org 12 Sep '12

12 Sep '12

Full_Name: Howard Chu Version: 2.4.32 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.255) Submitted by: hyc mdb_tool_entry_next() keeps a read-only cursor open, which prevents free pages from being reclaimed. Fix coming shortly.

1 0

Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by hyc＠symas.com 12 Sep '12

12 Sep '12

Frank.Swasey(a)uvm.edu wrote: > Full_Name: Francis Swasey > Version: 2.4.32 > OS: RHEL6.3 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.198.21.181) > > > In exploring converting to back_mdb, I have discovered a problem which results > in the following symptoms: Thanks for the report, fixed now in git master. > > ldapmodify with the following ldif: > > > dn: cn=COURSE-201209-94186,ou=Groups,dc=uvm,dc=edu > changetype: modify > delete: member > member: uid=pbirnbau,ou=people,dc=uvm,dc=edu > - > > fails with the following: > > ldap_modify: Other (e.g., implementation specific) error (80) > additional info: entry update failed > > syslog records the following: > > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 ACCEPT from > IP=132.198.100.216:57847 (IP=0.0.0.0:636) > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 TLS established > tls_ssf=256 ssf=256 > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 BIND > dn="cn=manager,dc=uvm,dc=edu" method=128 > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 BIND > dn="cn=manager,dc=uvm,dc=edu" mech=SIMPLE ssf=0 > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 RESULT tag=97 err=0 text= > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 MOD > dn="cn=COURSE-201209-94186,ou=Groups,dc=uvm,dc=edu" > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 MOD attr=member > Sep 11 14:14:23 ldap6dev slapd[6456]: slap_queue_csn: queing 0x7fdb6bffd0a0 > 20120911181423.401038Z#000000#000#000000 > Sep 11 14:14:23 ldap6dev slapd[6456]: mdb_id2entry_put: mdb_put failed: No space > left on device(28) "cn=course-201209-94186,ou=groups,dc=uvm,dc=edu" > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 RESULT tag=103 err=80 > text=entry update failed > Sep 11 14:14:23 ldap6dev slapd[6456]: slap_graduate_commit_csn: removing > 0x7fdb54002970 20120911181423.401038Z#000000#000#000000 > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=2 UNBIND > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 closed > > gdb points to the return ENOSPC at line 4806 of mdb_node_add > > -- -- 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#7383) slapd startup issue with mdb
by michael＠stroeder.com 11 Sep '12

11 Sep '12

This is a cryptographically signed message in MIME format. --------------ms030701090404000009030901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable marco(a)schirrmeister.net wrote: > Normally I also only added an index where I saw the candidate message i= n the log. Even when there's a warning about non-indexed searches in syslog I won't = index all attributes mentioned in the message without further analyzing the fil= ter. IMHO there's no point to index additional attributes if one of the indexe= d attributes already narrows the set of search candidates to one. One examp= le are filters with (uid=3Dname) with eq-index on uid. Ciao, Michael. --------------ms030701090404000009030901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwOTExMjAxOTU1WjAjBgkq hkiG9w0BCQQxFgQU+0E5Hxed6F+8Fdmsr2y1whu833MwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAPPc18RzIfVnUVnXD2xBJwbbny8UE6R9+LKbdLJlPCmiKuq7iUlKvLLTJdI15gXDrWokI NH9COp2ZbUrSjmJGYufpH4lx+FXGG75YVgnxyaFyeL3WA9v/G6reiu2UT3971v6eFEMqDEjB DaP3aJ1sme86uYuRQSTyfzC2EPjww1gS5fXgOhKlEtbbdg5ltgZP6osdKX+qr0ueOBmiEs1g LyGktHeq8LAFxnWvNh50tLuLutr/vnIdnsLlw888GQSXtUQl3ugsI0q+AUv6bSmrGcImbvXK ZqeTa6JMqBxPQk5u56dCBqujjvDSCXKG1uan7packG1NeyGVZ/anPyAxhQAAAAAAAA== --------------ms030701090404000009030901--

1 0

Re: (ITS#7383) slapd startup issue with mdb
by marco＠schirrmeister.net 11 Sep '12

11 Sep '12

On Sep 11, 2012, at 8:14 PM, hyc(a)symas.com wrote: > marco(a)schirrmeister.net wrote: >> Full_Name: Marco Schirrmeister >> Version: 2.4.32 >> OS: CentOS6 x86_64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.59.6.160) >> >> >> I'm testing mdb since the last versions with our dataset. >> If I use my production config slapd does't start up. >> >> The following is in the log file. >> >> Sep 11 16:48:37 ds71 slapd2.4[8349]: @(#) $OpenLDAP: slapd 2.4.32 (Sep 6 2012 >> 13:50:54) $#012#011mschirrmeister@defrsl6bh2.ogilvy.com:/home/mschirrmeister/rpmbuild/BUILD/openldap-2.4.32/servers/slapd >> Sep 11 16:48:37 ds71 slapd2.4[8349]: mdb_attr_dbs: database "dc=ogilvy,dc=com": >> mdb_open(omgPublishDate) failed: Too many open files in system (23). >> Sep 11 16:48:37 ds71 slapd2.4[8349]: backend_startup_one (type=mdb, >> suffix="dc=ogilvy,dc=com"): bi_db_open failed! (23) >> Sep 11 16:48:37 ds71 slapd2.4[8349]: slapd stopped. >> >> My /etc/security/limits.conf file has already the following entries. >> * soft nofile 65535 >> * hard nofile 65535 >> >> No matter what I try on the OS side, the error above comes up. >> >> I have about 130 index attributes in my config. Looks to me that this is the >> problem. >> If I comment 8 attributes, slapd starts fine. > > There is a hardcoded limit of 128. This same limit exists in back-bdb/hdb. You > can just edit back-mdb.h (or back-bdb.h) to raise the limit. Change the > MDB_INDICES (or BDB_INDICES) definition. > > Congratulations, no one else has hit this limit in back-bdb in the past 12 > years. Seems likely to me that you're indexing too much, but there's not > enough information here to judge. Ok, thanks for that information. I will try to increase it. But it's weird that there is no error with bdb on startup. I looked at my back-bdb.h and it has 128. I'm definitely over this number. You are right, some are too much and I could maybe remove a few indexes. Some defaults. But our own schema extension is quite long and many of those attributes are used in searches from the various apps. Normally I also only added an index where I saw the candidate message in the log. So this is then also no bug and we can close it. Sorry for being to fast with an ITS. -- Marco

1 0

(ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by Frank.Swasey＠uvm.edu 11 Sep '12

11 Sep '12

Full_Name: Francis Swasey Version: 2.4.32 OS: RHEL6.3 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.198.21.181) In exploring converting to back_mdb, I have discovered a problem which results in the following symptoms: ldapmodify with the following ldif: dn: cn=COURSE-201209-94186,ou=Groups,dc=uvm,dc=edu changetype: modify delete: member member: uid=pbirnbau,ou=people,dc=uvm,dc=edu - fails with the following: ldap_modify: Other (e.g., implementation specific) error (80) additional info: entry update failed syslog records the following: Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 ACCEPT from IP=132.198.100.216:57847 (IP=0.0.0.0:636) Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 TLS established tls_ssf=256 ssf=256 Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 BIND dn="cn=manager,dc=uvm,dc=edu" method=128 Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 BIND dn="cn=manager,dc=uvm,dc=edu" mech=SIMPLE ssf=0 Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 RESULT tag=97 err=0 text= Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 MOD dn="cn=COURSE-201209-94186,ou=Groups,dc=uvm,dc=edu" Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 MOD attr=member Sep 11 14:14:23 ldap6dev slapd[6456]: slap_queue_csn: queing 0x7fdb6bffd0a0 20120911181423.401038Z#000000#000#000000 Sep 11 14:14:23 ldap6dev slapd[6456]: mdb_id2entry_put: mdb_put failed: No space left on device(28) "cn=course-201209-94186,ou=groups,dc=uvm,dc=edu" Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 RESULT tag=103 err=80 text=entry update failed Sep 11 14:14:23 ldap6dev slapd[6456]: slap_graduate_commit_csn: removing 0x7fdb54002970 20120911181423.401038Z#000000#000#000000 Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=2 UNBIND Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 closed gdb points to the return ENOSPC at line 4806 of mdb_node_add

1 0

Re: (ITS#7383) slapd startup issue with mdb
by hyc＠symas.com 11 Sep '12

11 Sep '12

marco(a)schirrmeister.net wrote: > Full_Name: Marco Schirrmeister > Version: 2.4.32 > OS: CentOS6 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.59.6.160) > > > I'm testing mdb since the last versions with our dataset. > If I use my production config slapd does't start up. > > The following is in the log file. > > Sep 11 16:48:37 ds71 slapd2.4[8349]: @(#) $OpenLDAP: slapd 2.4.32 (Sep 6 2012 > 13:50:54) $#012#011mschirrmeister@defrsl6bh2.ogilvy.com:/home/mschirrmeister/rpmbuild/BUILD/openldap-2.4.32/servers/slapd > Sep 11 16:48:37 ds71 slapd2.4[8349]: mdb_attr_dbs: database "dc=ogilvy,dc=com": > mdb_open(omgPublishDate) failed: Too many open files in system (23). > Sep 11 16:48:37 ds71 slapd2.4[8349]: backend_startup_one (type=mdb, > suffix="dc=ogilvy,dc=com"): bi_db_open failed! (23) > Sep 11 16:48:37 ds71 slapd2.4[8349]: slapd stopped. > > My /etc/security/limits.conf file has already the following entries. > * soft nofile 65535 > * hard nofile 65535 > > No matter what I try on the OS side, the error above comes up. > > I have about 130 index attributes in my config. Looks to me that this is the > problem. > If I comment 8 attributes, slapd starts fine. There is a hardcoded limit of 128. This same limit exists in back-bdb/hdb. You can just edit back-mdb.h (or back-bdb.h) to raise the limit. Change the MDB_INDICES (or BDB_INDICES) definition. Congratulations, no one else has hit this limit in back-bdb in the past 12 years. Seems likely to me that you're indexing too much, but there's not enough information here to judge. -- -- 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#7384) Assert Crash in ppolicy_ctrls_cleanup
by ghola＠rebelbase.com 11 Sep '12

11 Sep '12

Full_Name: Duncan Idaho Version: 2.4.32 OS: Centos 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.148.0.72) We are seeing this a few times a week in our environment. #0 0x0000003874c30265 in raise () from /lib64/libc.so.6 #1 0x0000003874c31d10 in abort () from /lib64/libc.so.6 #2 0x0000003874c296e6 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000055c369 in ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10, oldctrls=0x11251620) at ppolicy.c:870 #4 0x000000000055c4aa in ppolicy_ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10) at ppolicy.c:895 #5 0x0000000000442a46 in slap_cleanup_play (op=0x11144d40, rs=0x42e3cc10) at result.c:541 #6 0x0000000000443229 in send_ldap_response (op=0x11144d40, rs=0x42e3cc10) at result.c:733 #7 0x0000000000443a5d in slap_send_ldap_result (op=0x11144d40, rs=0x42e3cc10) at result.c:860 #8 0x000000000052d7d7 in hdb_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:158 #9 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, which=op_bind, oi=0x10af8670, on=0x0) at backover.c:671 #10 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, which=op_bind) at backover.c:723 #11 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at backover.c:738 #12 0x0000000000514136 in relay_back_op (op=0x11144d40, rs=0x42e3cc10, which=0) at op.c:210 #13 0x00000000005142b9 in relay_back_op_bind (op=0x11144d40, rs=0x42e3cc10) at op.c:243 #14 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, which=op_bind, oi=0x10af97f0, on=0x0) at backover.c:671 #15 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, which=op_bind) at backover.c:723 #16 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at backover.c:738 #17 0x000000000045520d in fe_op_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:383 #18 0x000000000045493c in do_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:205 #19 0x000000000042cbd4 in connection_operation (ctx=0x42e3cd60, arg_v=0x11144d40) at connection.c:1150 #20 0x000000000042d159 in connection_read_thread (ctx=0x42e3cd60, argv=0xc7) at connection.c:1286 #21 0x000000000058c6c1 in ldap_int_thread_pool_wrapper (xpool=0x109dfe80) at tpool.c:688 #22 0x000000387540673d in start_thread () from /lib64/libpthread.so.0 #23 0x0000003874cd3d1d in clone () from /lib64/libc.so.6 #24 0x0000000000000000 in ?? ()

1 0

(ITS#7383) slapd startup issue with mdb
by marco＠schirrmeister.net 11 Sep '12

11 Sep '12

Full_Name: Marco Schirrmeister Version: 2.4.32 OS: CentOS6 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.59.6.160) I'm testing mdb since the last versions with our dataset. If I use my production config slapd does't start up. The following is in the log file. Sep 11 16:48:37 ds71 slapd2.4[8349]: @(#) $OpenLDAP: slapd 2.4.32 (Sep 6 2012 13:50:54) $#012#011mschirrmeister@defrsl6bh2.ogilvy.com:/home/mschirrmeister/rpmbuild/BUILD/openldap-2.4.32/servers/slapd Sep 11 16:48:37 ds71 slapd2.4[8349]: mdb_attr_dbs: database "dc=ogilvy,dc=com": mdb_open(omgPublishDate) failed: Too many open files in system (23). Sep 11 16:48:37 ds71 slapd2.4[8349]: backend_startup_one (type=mdb, suffix="dc=ogilvy,dc=com"): bi_db_open failed! (23) Sep 11 16:48:37 ds71 slapd2.4[8349]: slapd stopped. My /etc/security/limits.conf file has already the following entries. * soft nofile 65535 * hard nofile 65535 No matter what I try on the OS side, the error above comes up. I have about 130 index attributes in my config. Looks to me that this is the problem. If I comment 8 attributes, slapd starts fine. I did not find anything about index limits. Is this a bug in mdb? I'm not able to create stacktrace. When I run slapd via gdb, output is this. Program exited with code 01. (gdb) bt full No stack. (gdb) If you can let me know how to do it, I can provide a trace. My config looks like below. I omitted all our internal attributes. --------- include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/corba.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/java.schema include /usr/share/openldap2.4/schema/krb5-kdc.schema include /usr/share/openldap2.4/schema/kerberosobject.schema include /usr/share/openldap2.4/schema/misc.schema include /usr/share/openldap2.4/schema/nis.schema include /usr/share/openldap2.4/schema/openldap.schema include /usr/share/openldap2.4/schema/autofs.schema include /usr/share/openldap2.4/schema/samba.schema include /usr/share/openldap2.4/schema/kolab.schema include /usr/share/openldap2.4/schema/calendar.schema include /usr/share/openldap2.4/schema/sudo.schema include /usr/share/openldap2.4/schema/dhcp.schema include /usr/share/openldap2.4/schema/ldapns.schema include /etc/openldap2.4/slapd.access.ogilvy.conf pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args modulepath /usr/lib64/oldap24/openldap2.4 moduleload back_monitor.la moduleload accesslog.la moduleload syncprov.la moduleload auditlog.la TLSCertificateFile /etc/pki/tls/certs/ogilvy.com.crt TLSCertificateKeyFile /etc/pki/tls/private/ogilvy.com_unsec.rsa TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt loglevel stats sasl-secprops noplain,noanonymous,noactive serverID 40 ldap://ds71.ogilvy.com database mdb suffix "dc=ogilvy,dc=com" rootdn "cn=manager,dc=ogilvy,dc=com" rootpw xxx directory /var/lib/ldap2.4/ogilvy.com limits dn.exact="cn=manager,dc=ogilvy,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="uid=replicator,ou=admin,dc=ogilvy,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits group/ogilvyGroup/uniqueMember="cn=svcgrp-unlimitedsearch,ou=groups,dc=ogilvy,dc=com" size.soft=unlimited size.hard=unlimited sizelimit 90000 checkpoint 256 5 conn_max_pending_auth 2000 dbnosync maxsize 10485760000 monitoring on overlay syncprov syncprov-checkpoint 256 5 syncprov-sessionlog 5000 database config rootdn "cn=admin,cn=config" rootpw xxx include /etc/openldap2.4/slapd.access.config.conf database monitor rootdn cn=monitor rootpw xxx ------- -- Marco

1 0

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2012