openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

Re: (ITS#7382) slapadd segfaults (during freeing resources)
by hyc＠symas.com 09 Sep '12

09 Sep '12

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: OPENLDAP_REL_ENG > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:9feb:ff02:2958:c83c:2589:166d) > > > Hi, Looks like you're mixing different libldaps in the same process. libldap init.c:484 is not what your backtrace shows. At least, not in the RE24 branch. Closing this ITS, your environment is invalid. > root@srv:/home/tester/src/openldap# gdb > /home/tester/src/openldap/servers/slapd/slapadd > GNU gdb (GDB) 7.4.1-debian > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /home/tester/src/openldap/servers/slapd/slapadd...done. > (gdb) run -v -F /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l > /tmp/example_data.ldif > Starting program: /home/tester/src/openldap/servers/slapd/slapadd -v -F > /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l /tmp/example_data.ldif > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > 504cc479 mdb_id2entry_put: mdb_put failed: MDB_KEYEXIST: Key/data pair already > exists(-30799) "dc=example,dc=com" > 504cc479 => mdb_tool_entry_put: id2entry_add failed: err=-30799 > 504cc479 => mdb_tool_entry_put: txn_aborted! MDB_KEYEXIST: Key/data pair already > exists (-30799) > slapadd: could not add entry dn="dc=example,dc=com" (line=1): txn_aborted! > MDB_KEYEXIST: Key/data pair already exists (-30799) > _### 16.13% eta none elapsed none spd 501.5 k/s > Closing DB... > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) bt full > #0 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 > No symbol table info available. > #1 0x0000000000592f46 in ber_memfree_x (p=0x426f6f462f6d6f74, ctx=0x0) at > memory.c:152 > __PRETTY_FUNCTION__ = "ber_memfree_x" > #2 0x0000000000579f5f in ldap_free_urldesc (ludp=0x8fcd10) at url.c:1528 > No locals. > #3 0x0000000000579f15 in ldap_free_urllist (ludlist=0x8fcd10) at url.c:1516 > ludp = 0x8fcd10 > next = 0x7375632f6374652f > #4 0x00007ffff635b2b3 in ldap_int_destroy_global_options () at init.c:484 > gopts = 0x7ffff6599080 > #5 0x00007ffff7defef9 in ?? () from /lib64/ld-linux-x86-64.so.2 > No symbol table info available. > #6 0x00007ffff7df09ce in ?? () from /lib64/ld-linux-x86-64.so.2 > No symbol table info available. > #7 0x00007ffff7deabd6 in ?? () from /lib64/ld-linux-x86-64.so.2 > No symbol table info available. > #8 0x00007ffff79d12ec in ?? () from /lib/x86_64-linux-gnu/libdl.so.2 > No symbol table info available. > #9 0x00007ffff79d100f in dlclose () from /lib/x86_64-linux-gnu/libdl.so.2 > No symbol table info available. > #10 0x00007ffff77c8291 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 > No symbol table info available. > #11 0x00007ffff77bfae1 in sasl_common_done () from > /usr/lib/x86_64-linux-gnu/libsasl2.so.2 > No symbol table info available. > #12 0x00000000004b34d4 in slap_sasl_destroy () at sasl.c:1190 > No locals. > #13 0x0000000000482039 in slap_destroy () at init.c:249 > rc = 0 > #14 0x00000000004ddbc8 in slap_tool_destroy () at slapcommon.c:932 > rc = 0 > #15 0x00000000004db86f in slapadd (argc=8, argv=0x7fffffffe648) at > slapadd.c:502 > textbuf = "\000xn_aborted! MDB_KEYEXIST: Key/data pair already exists > (-30799)", '\000' <repeats 191 times> > textlen = 256 > erec = {e = 0x8db288, lineno = 1, nextline = 14} > bvtext = {bv_len = 256, bv_val = 0x7fffffffe300 ""} > thr = 4270934 > id = 18446744073709551615 > prev = 0x0 > ldifrc = 1 > rc = 1 > stat_buf = {st_dev = 2307, st_ino = 149868, st_nlink = 1, st_mode = > 33188, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 2225, > st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1347128272, > tv_nsec = 0}, st_mtim = {tv_sec = 1347128189, tv_nsec = 0}, st_ctim = { > tv_sec = 1347128189, tv_nsec = 0}, __unused = {0, 0, 0}} > #16 0x000000000041e688 in main (argc=8, argv=0x7fffffffe648) at main.c:410 > i = 0 > no_detach = 0 > ---Type <return> to continue, or q <return> to quit--- > rc = 1 > urls = 0x0 > username = 0x0 > groupname = 0x0 > sandbox = 0x0 > syslogUser = 160 > pid = 32767 > waitfds = {0, 0} > g_argc = 8 > g_argv = 0x7fffffffe648 > configfile = 0x0 > configdir = 0x0 > serverName = 0x7fffffffe8c3 "slapadd" > serverMode = 1 > scp = 0x0 > scp_entry = 0x0 > debug_unknowns = 0x0 > syslog_unknowns = 0x0 > serverNamePrefix = 0x596388 "" > l = 140733193388033 > slapd_pid_file_unlink = 0 > slapd_args_file_unlink = 0 > firstopt = 1 > __PRETTY_FUNCTION__ = "main" > > -- -- 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#7382) slapadd segfaults (during freeing resources)
by daniel＠pluta.biz 09 Sep '12

09 Sep '12

Full_Name: Daniel Pluta Version: OPENLDAP_REL_ENG OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:2958:c83c:2589:166d) Hi, root@srv:/home/tester/src/openldap# gdb /home/tester/src/openldap/servers/slapd/slapadd GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/tester/src/openldap/servers/slapd/slapadd...done. (gdb) run -v -F /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l /tmp/example_data.ldif Starting program: /home/tester/src/openldap/servers/slapd/slapadd -v -F /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l /tmp/example_data.ldif [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 504cc479 mdb_id2entry_put: mdb_put failed: MDB_KEYEXIST: Key/data pair already exists(-30799) "dc=example,dc=com" 504cc479 => mdb_tool_entry_put: id2entry_add failed: err=-30799 504cc479 => mdb_tool_entry_put: txn_aborted! MDB_KEYEXIST: Key/data pair already exists (-30799) slapadd: could not add entry dn="dc=example,dc=com" (line=1): txn_aborted! MDB_KEYEXIST: Key/data pair already exists (-30799) _### 16.13% eta none elapsed none spd 501.5 k/s Closing DB... Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt full #0 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x0000000000592f46 in ber_memfree_x (p=0x426f6f462f6d6f74, ctx=0x0) at memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #2 0x0000000000579f5f in ldap_free_urldesc (ludp=0x8fcd10) at url.c:1528 No locals. #3 0x0000000000579f15 in ldap_free_urllist (ludlist=0x8fcd10) at url.c:1516 ludp = 0x8fcd10 next = 0x7375632f6374652f #4 0x00007ffff635b2b3 in ldap_int_destroy_global_options () at init.c:484 gopts = 0x7ffff6599080 #5 0x00007ffff7defef9 in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #6 0x00007ffff7df09ce in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #7 0x00007ffff7deabd6 in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #8 0x00007ffff79d12ec in ?? () from /lib/x86_64-linux-gnu/libdl.so.2 No symbol table info available. #9 0x00007ffff79d100f in dlclose () from /lib/x86_64-linux-gnu/libdl.so.2 No symbol table info available. #10 0x00007ffff77c8291 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 No symbol table info available. #11 0x00007ffff77bfae1 in sasl_common_done () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 No symbol table info available. #12 0x00000000004b34d4 in slap_sasl_destroy () at sasl.c:1190 No locals. #13 0x0000000000482039 in slap_destroy () at init.c:249 rc = 0 #14 0x00000000004ddbc8 in slap_tool_destroy () at slapcommon.c:932 rc = 0 #15 0x00000000004db86f in slapadd (argc=8, argv=0x7fffffffe648) at slapadd.c:502 textbuf = "\000xn_aborted! MDB_KEYEXIST: Key/data pair already exists (-30799)", '\000' <repeats 191 times> textlen = 256 erec = {e = 0x8db288, lineno = 1, nextline = 14} bvtext = {bv_len = 256, bv_val = 0x7fffffffe300 ""} thr = 4270934 id = 18446744073709551615 prev = 0x0 ldifrc = 1 rc = 1 stat_buf = {st_dev = 2307, st_ino = 149868, st_nlink = 1, st_mode = 33188, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 2225, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1347128272, tv_nsec = 0}, st_mtim = {tv_sec = 1347128189, tv_nsec = 0}, st_ctim = { tv_sec = 1347128189, tv_nsec = 0}, __unused = {0, 0, 0}} #16 0x000000000041e688 in main (argc=8, argv=0x7fffffffe648) at main.c:410 i = 0 no_detach = 0 ---Type <return> to continue, or q <return> to quit--- rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 32767 waitfds = {0, 0} g_argc = 8 g_argv = 0x7fffffffe648 configfile = 0x0 configdir = 0x0 serverName = 0x7fffffffe8c3 "slapadd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x596388 "" l = 140733193388033 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by h.b.furuseth＠usit.uio.no 06 Sep '12

06 Sep '12

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> This is worse with a database with is intended to be used by >> different users (A and B): > (...) >> mdb_env_setup_locks() can sem_unlink both semaphores before doing >> anything else, so that reopening a database as root will clean up. >> Drop the error checks of sem_unlink (so both get called), instead >> use O_EXCL in sem_open(,O_CREAT,,). Unless I'm missing something, >> the error checks just work like an emulation of O_EXCL anyway. > > The sem_unlink() and sem_open() sequence isn't ideal, certainly. I would > prefer to just use the existing semaphore. I just realized reusing the semaphores is a security problem: Anyone who can compute/read the semaphore names, can create the semaphores owned by themselves and then muck with them to sabotage someone else's mdb. I suppose the same goes for SysV semaphores. I don't know what the accepted way to deal with that is, but I suggest to unlink + O_EXCL as above for now, document the multi-uid restriction, and punt the rest until anyone who cares shows up. > Another possibility is to just use SysV semaphores instead of POSIX > semaphores. Then you can use the ipcs(1) command to manually cleanup. > (...) [later] > I'm also reminded that there is no defined behavior for SysV > semaphores in threads, they are only speciried for inter-process > synchronization. So forget that... I expect the work-around is to use them for IPC only, and wrap them in process-local mutexes in the MDB_env for thread sync. -- Hallvard

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs