Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by marco＠schirrmeister.net
--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--
9 years, 4 months
Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by hyc＠symas.com
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/
9 years, 4 months
Re: (ITS#7383) slapd startup issue with mdb
by michael＠stroeder.com
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--
9 years, 4 months
Re: (ITS#7383) slapd startup issue with mdb
by marco＠schirrmeister.net
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
9 years, 4 months
(ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by Frank.Swasey＠uvm.edu
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
9 years, 4 months
Re: (ITS#7383) slapd startup issue with mdb
by hyc＠symas.com
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/
9 years, 4 months
(ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by ghola＠rebelbase.com
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 ?? ()
9 years, 4 months
(ITS#7383) slapd startup issue with mdb
by marco＠schirrmeister.net
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
9 years, 4 months
