- openldap-bugs - openldap.org

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 23 Jan '09

23 Jan '09

--0-155382548-1232743879=:83198 Content-Type: text/plain; charset=us-ascii Howard, I'm not sure the information needed. I look as : If ldapsearch finds one or more entries, the attributes specified by attrs are returned. If * is listed, all user attributes are returned. If + is listed, all operational attributes are returned. If no attrs are listed, all user attributes are returned. So I thought the empty attrs would return all information. Now with + I could see some other information but notthing related with cache. What I runned was ldapsearch -LLL -x -b "cn=monitor" -H ldap://10.142.15.42:389 + I'm also running at this time with the same problem openldap 2.2.26. Please see file attached with monitor information. Looks like that ever cache started to be used the cachesize or idlcachesize never restrict memory allocation. Also there is never a cache free. The code appears to have some LRU something that is supposed to release cache. I tested version 2.2.6, 2.3.4, 2.3.10, 2.4.11, 2.4.13 and I could never see after cache was implemented slapd restricting the memory usage. I use pre-compiled versions and compiled by myself. I do not think this is a 32 bits or 64 bits problem since the only difference is that 32 bits process will not be able to use more than 3GB of memory. Then in a 64 bits machine with 3GB of physical memory the same bahavior should occur if slapd doesn't use some memory cache restriction. By the way I see it now is that if you have a DB on disk that is bigger than your physical memory, or in 32 bits machines 3GB, then if you start a LDIF backup, have many random access or start replication slapd will consume all available memory and crash. Please let me know if this file is ok and if not which ldapsearch notation should I use. Thanks a lot! Rodrigo. --- On Fri, 1/23/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)openldap.org > Date: Friday, January 23, 2009, 5:37 PM > Rodrigo Costa wrote: > > Howard, > > > > I had the monitor enabled. But I could not see nothing > related to cache in its output. > > > > I executed the command : > > > > ldapsearch -LLL -x -b "cn=monitor" -H > ldap://10.142.15.42:389> monitor_2.txt > > > > It is supposed to be all information provided by > monitor, as I know. > > No, the monitoring info is in operational attributes, as > documented in the slapd-monitor manpage. You have to specify > that all attributes be returned, using "*" and > "+" on the search. > > -- -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP > http://www.openldap.org/project/ --0-155382548-1232743879=:83198 Content-Type: text/plain; name="monitor.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="monitor.txt" ZG46IGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv clNlcnZlcg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1v ZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQptb25pdG9yZWRJbmZv OiBAKCMpICRPcGVuTERBUDogc2xhcGQgMi4yLjI2IChNYXkgMjAgMjAwNSAx NzozMjoxNCkgJA0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0K aGFzU3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBjbj1PdmVybGF5LGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5l cg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRp bWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBj bj1UaW1lLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9u aXRvckNvbnRhaW5lcg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1 MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hl bWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IFRS VUUNCg0KZG46IGNuPUN1cnJlbnQsY249VGltZSxjbj1Nb25pdG9yDQpzdHJ1 Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KbW9uaXRvclRp bWVzdGFtcDogMjAwOTAxMjMyMjI4NDlaDQpjcmVhdGVUaW1lc3RhbXA6IDIw MDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1 MFoNCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVN0YXJ0LGNuPVRpbWUsY249TW9u aXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QN Cm1vbml0b3JUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KY3JlYXRlVGlt ZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAw OTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1h DQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1TdGF0aXN0aWNz LGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNv bnRhaW5lcg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1v ZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJl bnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IFRSVUUNCg0K ZG46IGNuPUJ5dGVzLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kc3RydWN0 dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ291bnRlck9iamVjdA0KY3JlYXRl VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRpbWVzdGFtcDog MjAwOTAxMjMyMTQwNTBaDQptb25pdG9yQ291bnRlcjogMjc3MDY3NzQ4DQpz dWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0 ZXM6IEZBTFNFDQoNCmRuOiBjbj1QRFUsY249U3RhdGlzdGljcyxjbj1Nb25p dG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2Jq ZWN0DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5 VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vbml0b3JDb3VudGVyOiAx MDAwMzIwDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNT dWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1SZWZlcnJhbHMsY249U3Rh dGlzdGljcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1v bml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIz MjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1v bml0b3JDb3VudGVyOiAwDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2No ZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1FbnRyaWVz LGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENs YXNzOiBtb25pdG9yQ291bnRlck9iamVjdA0KY3JlYXRlVGltZXN0YW1wOiAy MDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQw NTBaDQptb25pdG9yQ291bnRlcjogMTAwMDMwNQ0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0 Q2xhc3M6IG1vbml0b3JDb250YWluZXINCmNyZWF0ZVRpbWVzdGFtcDogMjAw OTAxMjMyMTQwNTBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUw Wg0KbW9uaXRvck9wSW5pdGlhdGVkOiAyNg0KbW9uaXRvck9wQ29tcGxldGVk OiAyNQ0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBjbj1CaW5kLGNuPU9wZXJhdGlvbnMs Y249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yT3Bl cmF0aW9uDQptb25pdG9yT3BJbml0aWF0ZWQ6IDkNCm1vbml0b3JPcENvbXBs ZXRlZDogOQ0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1v ZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJl bnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoN CmRuOiBjbj1VbmJpbmQsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1 Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCm1vbml0b3JP cEluaXRpYXRlZDogOA0KbW9uaXRvck9wQ29tcGxldGVkOiA4DQpjcmVhdGVU aW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAy MDA5MDEyMzIxNDA1MFoNCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hl bWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUFkZCxjbj1P cGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczog bW9uaXRvck9wZXJhdGlvbg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25p dG9yT3BDb21wbGV0ZWQ6IDANCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMy MTQwNTBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0Kc3Vi c2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVz OiBGQUxTRQ0KDQpkbjogY249RGVsZXRlLGNuPU9wZXJhdGlvbnMsY249TW9u aXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9u DQptb25pdG9yT3BJbml0aWF0ZWQ6IDANCm1vbml0b3JPcENvbXBsZXRlZDog MA0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRp bWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBj bj1Nb2RyZG4sY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFs T2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCm1vbml0b3JPcEluaXRp YXRlZDogMA0KbW9uaXRvck9wQ29tcGxldGVkOiAwDQpjcmVhdGVUaW1lc3Rh bXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEy MzIxNDA1MFoNCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhh c1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1vZGlmeSxjbj1PcGVy YXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9u aXRvck9wZXJhdGlvbg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9y T3BDb21wbGV0ZWQ6IDANCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQw NTBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0Kc3Vic2No ZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBG QUxTRQ0KDQpkbjogY249Q29tcGFyZSxjbj1PcGVyYXRpb25zLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0K bW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDAN CmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQptb2RpZnlUaW1l c3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNu PVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249 U2VhcmNoLGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9i amVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9uDQptb25pdG9yT3BJbml0aWF0 ZWQ6IDkNCm1vbml0b3JPcENvbXBsZXRlZDogOA0KY3JlYXRlVGltZXN0YW1w OiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMy MTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNT dWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1BYmFuZG9uLGNuPU9wZXJh dGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25p dG9yT3BlcmF0aW9uDQptb25pdG9yT3BJbml0aWF0ZWQ6IDANCm1vbml0b3JP cENvbXBsZXRlZDogMA0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1 MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hl bWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZB TFNFDQoNCmRuOiBjbj1FeHRlbmRlZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0K bW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDAN CmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQptb2RpZnlUaW1l c3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNu PVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249 TG9nLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv ckNvbnRhaW5lcg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoN Cm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFT dWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNF DQoNCmRuOiBjbj1XYWl0ZXJzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmpl Y3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY3JlYXRlVGltZXN0YW1wOiAy MDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQw NTBaDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJv cmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPVdyaXRlLGNuPVdhaXRlcnMsY249 TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ291bnRl ck9iamVjdA0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1v ZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQptb25pdG9yQ291bnRl cjogMA0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249UmVhZCxjbj1XYWl0ZXJzLGNu PU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvdW50 ZXJPYmplY3QNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpt b2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9uaXRvckNvdW50 ZXI6IDENCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1 Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUNvbm5lY3Rpb25zLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5l cg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRp bWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNu PUNvbm5lY3Rpb24gOCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1 Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb25uZWN0aW9uDQpjcmVhdGVU aW1lc3RhbXA6IDIwMDkwMTIzMjIyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAy MDA5MDEyMzIyMjg0OVoNCm1vbml0b3JlZEluZm86IDggOiAzIDogMi8xLzAv MSA6IDIvMi8wIDogcnggOiBjbj1hbm9ueW1vdXMgOiBsZGFwOi8vMTAuMTQy LjE1Lg0KIDQyOjM4OSA6IHVua25vd24gOiBJUD0xMC4xNDIuMTUuNDY6MzU0 ODAgOiBJUD0xMC4xNDIuMTUuNDI6Mzg5IDogMjAwOTAxMjMyMjI4DQogNDha IDogMjAwOTAxMjMyMjI4NDlaDQptb25pdG9yQ29ubmVjdGlvbk51bWJlcjog OA0KbW9uaXRvckNvbm5lY3Rpb25Mb2NhbEFkZHJlc3M6IElQPTEwLjE0Mi4x NS40MjozODkNCm1vbml0b3JDb25uZWN0aW9uUGVlckFkZHJlc3M6IElQPTEw LjE0Mi4xNS40NjozNTQ4MA0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNj aGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249Q3VycmVu dCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0 Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdGVUaW1lc3RhbXA6 IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIx NDA1MFoNCm1vbml0b3JDb3VudGVyOiAxDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBj bj1Ub3RhbCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFs T2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdGVUaW1l c3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5 MDEyMzIxNDA1MFoNCm1vbml0b3JDb3VudGVyOiA5DQpzdWJzY2hlbWFTdWJl bnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoN CmRuOiBjbj1UTFMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNz OiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIz MjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCnN1 YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRl czogRkFMU0UNCg0KZG46IGNuPVNBU0wsY249TW9uaXRvcg0Kc3RydWN0dXJh bE9iamVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdGVUaW1lc3Rh bXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEy MzIxNDA1MFoNCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhh c1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVRocmVhZHMsY249TW9u aXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVy DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGlt ZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vbml0b3JlZEluZm86IG1heD0x Ng0KbW9uaXRvcmVkSW5mbzogYmFja2xvYWQ9MQ0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249QmFja2VuZHMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENs YXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkw MTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoN Cm1vbml0b3JlZEluZm86IG1vbml0b3INCm1vbml0b3JlZEluZm86IGJkYg0K c3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5h dGVzOiBUUlVFDQoNCmRuOiBjbj1CYWNrZW5kIDAsY249QmFja2VuZHMsY249 TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmpl Y3QNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQptb2RpZnlU aW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9uaXRvcmVkSW5mbzogYmRi DQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjQuMS40MjAzLjY2Ni41LjkN CnN1cHBvcnRlZENvbnRyb2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQpz dXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjQuMS40MjAzLjY2Ni41LjINCnN1 cHBvcnRlZENvbnRyb2w6IDEuMi44NDAuMTEzNTU2LjEuNC4zMTkNCnN1cHBv cnRlZENvbnRyb2w6IDEuMy42LjEuNC4xLjQyMDMuMS4xMC4xDQpzdXBwb3J0 ZWRDb250cm9sOiAxLjIuODI2LjAuMS4zMzQ4MTAuMi4zDQpzdXBwb3J0ZWRD b250cm9sOiAxLjIuODQwLjExMzU1Ni4xLjQuMTQxMw0Kc3Vic2NoZW1hU3Vi ZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0K DQpkbjogY249QmFja2VuZCAxLGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdGVU aW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAy MDA5MDEyMzIxNDA1MFoNCm1vbml0b3JlZEluZm86IG1vbml0b3INCnN1cHBv cnRlZENvbnRyb2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQpzdXBwb3J0 ZWRDb250cm9sOiAxLjIuODI2LjAuMS4zMzQ4MTAuMi4zDQpzdWJzY2hlbWFT dWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNF DQoNCmRuOiBjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9i amVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdGVUaW1lc3RhbXA6 IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIx NDA1MFoNCm1vbml0b3JDb250ZXh0OiBjbj1Nb25pdG9yDQpuYW1pbmdDb250 ZXh0czogb3U9SU5ERVhFUyxvPWFsY2F0ZWwsYz1mcg0KbmFtaW5nQ29udGV4 dHM6IG91PUNPTlRFTlQsbz1hbGNhdGVsLGM9ZnINCnN1YnNjaGVtYVN1YmVu dHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogVFJVRQ0KDQpk bjogY249RGF0YWJhc2UgMCxjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0Kc3Ry dWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCm1vbml0b3Jl ZEluZm86IGJkYg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoN Cm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpuYW1pbmdDb250 ZXh0czogb3U9Q09OVEVOVCxvPWFsY2F0ZWwsYz1mcg0Kc3Vic2NoZW1hU3Vi ZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0K DQpkbjogY249RGF0YWJhc2UgMSxjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0K c3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCm1vbml0 b3JlZEluZm86IGJkYg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1 MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpuYW1pbmdD b250ZXh0czogb3U9SU5ERVhFUyxvPWFsY2F0ZWwsYz1mcg0Kc3Vic2NoZW1h U3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxT RQ0KDQpkbjogY249RGF0YWJhc2UgMixjbj1EYXRhYmFzZXMsY249TW9uaXRv cg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCm1v bml0b3JlZEluZm86IG1vbml0b3INCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjMyMTQwNTBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0K bW9uaXRvckNvbnRleHQ6IGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5 OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46 IGNuPUxpc3RlbmVycyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xh c3M6IG1vbml0b3JDb250YWluZXINCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjMyMTQwNTBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0K c3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5h dGVzOiBUUlVFDQoNCmRuOiBjbj1MaXN0ZW5lciAwLGNuPUxpc3RlbmVycyxj bj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9i amVjdA0KbW9uaXRvckNvbm5lY3Rpb25Mb2NhbEFkZHJlc3M6IElQPTEwLjE0 Mi4xNS40MjozODkNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBa DQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0Kc3Vic2NoZW1h U3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxT RQ0KDQpkbjogY249TGlzdGVuZXIgMSxjbj1MaXN0ZW5lcnMsY249TW9uaXRv cg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCm1v bml0b3JDb25uZWN0aW9uTG9jYWxBZGRyZXNzOiBJUD0xMC4xNDIuMTUuMTcy OjM4OQ0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlm eVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRy eTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCg== --0-155382548-1232743879=:83198--

1 0

Re: Re: Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by adrien.futschik＠atosorigin.com 23 Jan '09

23 Jan '09

> No. Replication is supposed to work regardless of mode, refreshOnly / > refreshAndPersist should yield identical results. ... > There is still a bug here. You mean that the fact that N-way Multi-master doesn't replicate deletes properly when using "refreshOnly" is a bug ? But N-way Multi-master seams to be working correctly when using "refreshAndPersist". I see some reasons why using "refreshOnly" instead of "refreshAndPersist", will this be corrected in the next release of OpenLDAP ? What is recommended with OpenLDAP 2.4.11. Should we wait for the next stable release if we intend to use N-way Multi-master in production ? Best regards Adrien Futschik

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 23 Jan '09

23 Jan '09

--0-65098359-1232716543=:26208 Content-Type: text/plain; charset=us-ascii Howard, I had the monitor enabled. But I could not see nothing related to cache in its output. I executed the command : ldapsearch -LLL -x -b "cn=monitor" -H ldap://10.142.15.42:389 > monitor_2.txt It is supposed to be all information provided by monitor, as I know. Please see file attached with information. I still not sure what or which cache is consuming all memory. I do not understand why we place cache size definitions to slapd and it doesn't respect them. Regards, Rodrigo. --- On Thu, 1/22/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)openldap.org > Date: Thursday, January 22, 2009, 8:36 PM > rlvcosta(a)yahoo.com wrote: > > Quanah, > > > > I just used tcmalloc but I still with the same > behavior. slapd doesn't > > have limit for the cache and then it cannot run large > databases. > > As a side comment, we have already documented that about 1 > million entries is the practical limit for slapd on a 32 bit > machine. Since 64 bit machines are so common today, making > slapd perform well on a 32 bit machine is no longer a > priority. > > Also, by design, tcmalloc doesn't release freed memory > back to the OS, since it will most likely be needed again. > It's normal for the slapd process size to never shrink. > > One thing you can check is to add a "database > monitor" to your slapd configuration; one of the > entries under cn=monitor will report the number of items in > the back-bdb cache. Please provide this information here. > > -- -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP > http://www.openldap.org/project/ --0-65098359-1232716543=:26208 Content-Type: text/plain; name="monitor_2.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="monitor_2.txt" ZG46IGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBtb25pdG9yU2VydmVyDQpj bjogTW9uaXRvcg0KZGVzY3JpcHRpb246IFRoaXMgc3VidHJlZSBjb250YWlu cyBtb25pdG9yaW5nL21hbmFnaW5nIG9iamVjdHMuDQpkZXNjcmlwdGlvbjog VGhpcyBvYmplY3QgY29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgdGhpcyBz ZXJ2ZXIuDQpkZXNjcmlwdGlvbjogTW9zdCBvZiB0aGUgaW5mb3JtYXRpb24g aXMgaGVsZCBpbiBvcGVyYXRpb25hbCBhdHRyaWJ1dGVzLCB3aGljaCANCiBt dXN0IGJlIGV4cGxpY2l0bHkgcmVxdWVzdGVkLg0KDQpkbjogY249QmFja2Vu ZHMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JDb250YWluZXIN CmNuOiBCYWNrZW5kcw0KZGVzY3JpcHRpb246IFRoaXMgc3Vic3lzdGVtIGNv bnRhaW5zIGluZm9ybWF0aW9uIGFib3V0IGF2YWlsYWJsZSBiYWNrZW5kcy4N Cg0KZG46IGNuPUJhY2tlbmQgMCxjbj1CYWNrZW5kcyxjbj1Nb25pdG9yDQpv YmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjbjogQmFja2VuZCAwDQpz ZWVBbHNvOiBjbj1EYXRhYmFzZSAwLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9y DQoNCmRuOiBjbj1CYWNrZW5kIDEsY249QmFja2VuZHMsY249TW9uaXRvcg0K b2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY246IEJhY2tlbmQgMQ0K DQpkbjogY249QmFja2VuZCAyLGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCm9i amVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCmNuOiBCYWNrZW5kIDINCnNl ZUFsc286IGNuPURhdGFiYXNlIDEsY249RGF0YWJhc2VzLGNuPU1vbml0b3IN CnNlZUFsc286IGNuPURhdGFiYXNlIDIsY249RGF0YWJhc2VzLGNuPU1vbml0 b3INCg0KZG46IGNuPUJhY2tlbmQgMyxjbj1CYWNrZW5kcyxjbj1Nb25pdG9y DQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjbjogQmFja2VuZCAz DQpzZWVBbHNvOiBjbj1EYXRhYmFzZSAzLGNuPURhdGFiYXNlcyxjbj1Nb25p dG9yDQoNCmRuOiBjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpvYmplY3RD bGFzczogbW9uaXRvckNvbnRhaW5lcg0KY246IENvbm5lY3Rpb25zDQpkZXNj cmlwdGlvbjogVGhpcyBzdWJzeXN0ZW0gY29udGFpbnMgaW5mb3JtYXRpb24g YWJvdXQgY29ubmVjdGlvbnMuDQoNCmRuOiBjbj1Db25uZWN0aW9uIDMsY249 Q29ubmVjdGlvbnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JD b25uZWN0aW9uDQpjbjogQ29ubmVjdGlvbiAzDQoNCmRuOiBjbj1NYXggRmls ZSBEZXNjcmlwdG9ycyxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpvYmpl Y3RDbGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QNCmNuOiBNYXggRmlsZSBE ZXNjcmlwdG9ycw0KDQpkbjogY249VG90YWwsY249Q29ubmVjdGlvbnMsY249 TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpj bjogVG90YWwNCg0KZG46IGNuPUN1cnJlbnQsY249Q29ubmVjdGlvbnMsY249 TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpj bjogQ3VycmVudA0KDQpkbjogY249RGF0YWJhc2VzLGNuPU1vbml0b3INCm9i amVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpjbjogRGF0YWJhc2VzDQpk ZXNjcmlwdGlvbjogVGhpcyBzdWJzeXN0ZW0gY29udGFpbnMgaW5mb3JtYXRp b24gYWJvdXQgY29uZmlndXJlZCBkYXRhYmFzZXMuDQoNCmRuOiBjbj1Gcm9u dGVuZCxjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1v bml0b3JlZE9iamVjdA0KY246IEZyb250ZW5kDQoNCmRuOiBjbj1EYXRhYmFz ZSAwLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9u aXRvcmVkT2JqZWN0DQpjbjogRGF0YWJhc2UgMA0Kc2VlQWxzbzogY249QmFj a2VuZCAwLGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCg0KZG46IGNuPURhdGFi YXNlIDEsY249RGF0YWJhc2VzLGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBt b25pdG9yZWRPYmplY3QNCm9iamVjdENsYXNzOiBvbG1CREJEYXRhYmFzZQ0K Y246IERhdGFiYXNlIDENCnNlZUFsc286IGNuPUJhY2tlbmQgMixjbj1CYWNr ZW5kcyxjbj1Nb25pdG9yDQoNCmRuOiBjbj1EYXRhYmFzZSAyLGNuPURhdGFi YXNlcyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0 DQpvYmplY3RDbGFzczogb2xtQkRCRGF0YWJhc2UNCmNuOiBEYXRhYmFzZSAy DQpzZWVBbHNvOiBjbj1CYWNrZW5kIDIsY249QmFja2VuZHMsY249TW9uaXRv cg0KDQpkbjogY249RGF0YWJhc2UgMyxjbj1EYXRhYmFzZXMsY249TW9uaXRv cg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY246IERhdGFiYXNl IDMNCnNlZUFsc286IGNuPUJhY2tlbmQgMyxjbj1CYWNrZW5kcyxjbj1Nb25p dG9yDQoNCmRuOiBjbj1MaXN0ZW5lcnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xh c3M6IG1vbml0b3JDb250YWluZXINCmNuOiBMaXN0ZW5lcnMNCmRlc2NyaXB0 aW9uOiBUaGlzIHN1YnN5c3RlbSBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91 dCBhY3RpdmUgbGlzdGVuZXJzLg0KDQpkbjogY249TGlzdGVuZXIgMCxjbj1M aXN0ZW5lcnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9i amVjdA0KY246IExpc3RlbmVyIDANCmxhYmVsZWRVUkk6IGxkYXA6Ly8xMC4x NDIuMTUuNDI6Mzg5DQoNCmRuOiBjbj1MaXN0ZW5lciAxLGNuPUxpc3RlbmVy cyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpj bjogTGlzdGVuZXIgMQ0KbGFiZWxlZFVSSTogbGRhcDovLzEwLjE0Mi4xNS4x NzI6Mzg5DQoNCmRuOiBjbj1Mb2csY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6 IG1vbml0b3JDb250YWluZXINCmNuOiBMb2cNCmRlc2NyaXB0aW9uOiBUaGlz IHN1YnN5c3RlbSBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91dCBsb2dnaW5n Lg0KZGVzY3JpcHRpb246IFNldCB0aGUgYXR0cmlidXRlICJtYW5hZ2VkSW5m byIgdG8gdGhlIGRlc2lyZWQgbG9nIGxldmVscy4NCg0KZG46IGNuPU9wZXJh dGlvbnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JDb250YWlu ZXINCmNuOiBPcGVyYXRpb25zDQpkZXNjcmlwdGlvbjogVGhpcyBzdWJzeXN0 ZW0gY29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgcGVyZm9ybWVkIG9wZXJh dGlvbnMuDQoNCmRuOiBjbj1CaW5kLGNuPU9wZXJhdGlvbnMsY249TW9uaXRv cg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCmNuOiBCaW5kDQoN CmRuOiBjbj1VbmJpbmQsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpvYmpl Y3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY246IFVuYmluZA0KDQpkbjog Y249U2VhcmNoLGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xh c3M6IG1vbml0b3JPcGVyYXRpb24NCmNuOiBTZWFyY2gNCg0KZG46IGNuPUNv bXBhcmUsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczog bW9uaXRvck9wZXJhdGlvbg0KY246IENvbXBhcmUNCg0KZG46IGNuPU1vZGlm eSxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBtb25p dG9yT3BlcmF0aW9uDQpjbjogTW9kaWZ5DQoNCmRuOiBjbj1Nb2RyZG4sY249 T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvck9w ZXJhdGlvbg0KY246IE1vZHJkbg0KDQpkbjogY249QWRkLGNuPU9wZXJhdGlv bnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24N CmNuOiBBZGQNCg0KZG46IGNuPURlbGV0ZSxjbj1PcGVyYXRpb25zLGNuPU1v bml0b3INCm9iamVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9uDQpjbjogRGVs ZXRlDQoNCmRuOiBjbj1BYmFuZG9uLGNuPU9wZXJhdGlvbnMsY249TW9uaXRv cg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCmNuOiBBYmFuZG9u DQoNCmRuOiBjbj1FeHRlbmRlZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3IN Cm9iamVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9uDQpjbjogRXh0ZW5kZWQN Cg0KZG46IGNuPU92ZXJsYXlzLGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBt b25pdG9yQ29udGFpbmVyDQpjbjogT3ZlcmxheXMNCmRlc2NyaXB0aW9uOiBU aGlzIHN1YnN5c3RlbSBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91dCBhdmFp bGFibGUgb3ZlcmxheXMuDQoNCmRuOiBjbj1PdmVybGF5IDAsY249T3Zlcmxh eXMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0K Y246IE92ZXJsYXkgMA0KDQpkbjogY249U0FTTCxjbj1Nb25pdG9yDQpvYmpl Y3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY246IFNBU0wNCmRlc2NyaXB0 aW9uOiBUaGlzIHN1YnN5c3RlbSBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91 dCBTQVNMLg0KDQpkbjogY249U3RhdGlzdGljcyxjbj1Nb25pdG9yDQpvYmpl Y3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY246IFN0YXRpc3RpY3MNCmRl c2NyaXB0aW9uOiBUaGlzIHN1YnN5c3RlbSBjb250YWlucyBzdGF0aXN0aWNz Lg0KDQpkbjogY249Qnl0ZXMsY249U3RhdGlzdGljcyxjbj1Nb25pdG9yDQpv YmplY3RDbGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QNCmNuOiBCeXRlcw0K DQpkbjogY249UERVLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kb2JqZWN0 Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjbjogUERVDQoNCmRuOiBj bj1FbnRyaWVzLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kb2JqZWN0Q2xh c3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjbjogRW50cmllcw0KDQpkbjog Y249UmVmZXJyYWxzLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kb2JqZWN0 Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjbjogUmVmZXJyYWxzDQoN CmRuOiBjbj1UaHJlYWRzLGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBtb25p dG9yQ29udGFpbmVyDQpjbjogVGhyZWFkcw0KZGVzY3JpcHRpb246IFRoaXMg c3Vic3lzdGVtIGNvbnRhaW5zIGluZm9ybWF0aW9uIGFib3V0IHRocmVhZHMu DQoNCmRuOiBjbj1NYXgsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpvYmplY3RD bGFzczogbW9uaXRvcmVkT2JqZWN0DQpjbjogTWF4DQpkZXNjcmlwdGlvbjog TWF4aW11bSBudW1iZXIgb2YgdGhyZWFkcyBhcyBjb25maWd1cmVkDQoNCmRu OiBjbj1NYXggUGVuZGluZyxjbj1UaHJlYWRzLGNuPU1vbml0b3INCm9iamVj dENsYXNzOiBtb25pdG9yZWRPYmplY3QNCmNuOiBNYXggUGVuZGluZw0KZGVz Y3JpcHRpb246IE1heGltdW0gbnVtYmVyIG9mIHBlbmRpbmcgdGhyZWFkcw0K DQpkbjogY249T3Blbixjbj1UaHJlYWRzLGNuPU1vbml0b3INCm9iamVjdENs YXNzOiBtb25pdG9yZWRPYmplY3QNCmNuOiBPcGVuDQpkZXNjcmlwdGlvbjog TnVtYmVyIG9mIG9wZW4gdGhyZWFkcw0KDQpkbjogY249U3RhcnRpbmcsY249 VGhyZWFkcyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2Jq ZWN0DQpjbjogU3RhcnRpbmcNCmRlc2NyaXB0aW9uOiBOdW1iZXIgb2YgdGhy ZWFkcyBiZWluZyBzdGFydGVkDQoNCmRuOiBjbj1BY3RpdmUsY249VGhyZWFk cyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpj bjogQWN0aXZlDQpkZXNjcmlwdGlvbjogTnVtYmVyIG9mIGFjdGl2ZSB0aHJl YWRzDQoNCmRuOiBjbj1QZW5kaW5nLGNuPVRocmVhZHMsY249TW9uaXRvcg0K b2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY246IFBlbmRpbmcNCmRl c2NyaXB0aW9uOiBOdW1iZXIgb2YgcGVuZGluZyB0aHJlYWRzDQoNCmRuOiBj bj1CYWNrbG9hZCxjbj1UaHJlYWRzLGNuPU1vbml0b3INCm9iamVjdENsYXNz OiBtb25pdG9yZWRPYmplY3QNCmNuOiBCYWNrbG9hZA0KZGVzY3JpcHRpb246 IE51bWJlciBvZiBhY3RpdmUgcGx1cyBwZW5kaW5nIHRocmVhZHMNCg0KZG46 IGNuPVN0YXRlLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6 IG1vbml0b3JlZE9iamVjdA0KY246IFN0YXRlDQpkZXNjcmlwdGlvbjogVGhy ZWFkIHBvb2wgc3RhdGUNCg0KZG46IGNuPVJ1bnF1ZXVlLGNuPVRocmVhZHMs Y249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY246 IFJ1bnF1ZXVlDQpkZXNjcmlwdGlvbjogUXVldWUgb2YgcnVubmluZyB0aHJl YWRzIC0gYmVzaWRlcyB0aG9zZSBoYW5kbGluZyBvcGVyYXRpb25zDQoNCmRu OiBjbj1UYXNrbGlzdCxjbj1UaHJlYWRzLGNuPU1vbml0b3INCm9iamVjdENs YXNzOiBtb25pdG9yZWRPYmplY3QNCmNuOiBUYXNrbGlzdA0KZGVzY3JpcHRp b246IExpc3Qgb2YgcnVubmluZyBwbHVzIHN0YW5kYnkgdGhyZWFkcyAtIGJl c2lkZXMgdGhvc2UgaGFuZGxpbmcgb3BlDQogcmF0aW9ucw0KDQpkbjogY249 VGltZSxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5l cg0KY246IFRpbWUNCmRlc2NyaXB0aW9uOiBUaGlzIHN1YnN5c3RlbSBjb250 YWlucyBpbmZvcm1hdGlvbiBhYm91dCB0aW1lLg0KDQpkbjogY249U3RhcnQs Y249VGltZSxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2Jq ZWN0DQpjbjogU3RhcnQNCg0KZG46IGNuPUN1cnJlbnQsY249VGltZSxjbj1N b25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjbjogQ3Vy cmVudA0KDQpkbjogY249VXB0aW1lLGNuPVRpbWUsY249TW9uaXRvcg0Kb2Jq ZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY246IFVwdGltZQ0KDQpkbjog Y249VExTLGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBtb25pdG9yQ29udGFp bmVyDQpjbjogVExTDQpkZXNjcmlwdGlvbjogVGhpcyBzdWJzeXN0ZW0gY29u dGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgVExTLg0KDQpkbjogY249V2FpdGVy cyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0K Y246IFdhaXRlcnMNCmRlc2NyaXB0aW9uOiBUaGlzIHN1YnN5c3RlbSBjb250 YWlucyBpbmZvcm1hdGlvbiBhYm91dCByZWFkL3dyaXRlIHdhaXRlcnMuDQoN CmRuOiBjbj1SZWFkLGNuPVdhaXRlcnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xh c3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjbjogUmVhZA0KDQpkbjogY249 V3JpdGUsY249V2FpdGVycyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9u aXRvckNvdW50ZXJPYmplY3QNCmNuOiBXcml0ZQ0KDQo= --0-65098359-1232716543=:26208--

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 23 Jan '09

23 Jan '09

Rodrigo Costa wrote: > Howard, > > I had the monitor enabled. But I could not see nothing related to cache in its output. > > I executed the command : > > ldapsearch -LLL -x -b "cn=monitor" -H ldap://10.142.15.42:389> monitor_2.txt > > It is supposed to be all information provided by monitor, as I know. No, the monitoring info is in operational attributes, as documented in the slapd-monitor manpage. You have to specify that all attributes be returned, using "*" and "+" on the search. -- -- 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#5894) test039 fails: ldap_back_conn_delete: Assertion
by quanah＠zimbra.com 23 Jan '09

23 Jan '09

--On Wednesday, January 21, 2009 2:35 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > quanah(a)zimbra.com wrote: >> --On Saturday, January 17, 2009 3:25 PM +0000 michael(a)stroeder.com wrote: >> >>> Howard Chu wrote: >>>> michael(a)stroeder.com wrote: >>>>> Full_Name: Michael Str?der >>>>> Version: HEAD >>>>> OS: Linux >>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>> Submission from: (NULL) (84.163.100.169) >>>>> >>>>> >>>>> lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion >>>>> `!(*(&((lc))->lc_lcflags) >>>>> & (((0x00000020U))))' failed. >>>> I'm not seeing that here. Ran into a couple other problems though, >>>> fixed now in HEAD. Please re-test... >>> Now test008 hangs... >> >> Multiple runs of test008 work for me, using BDB 4.7.25 with all 3 >> patches, and HEAD CVS as of 1/20/2009 @ 12:00 PST. >> >> Did you fully rebuild OpenLDAP after the latest commits? What version >> of BDB are you using? Is it fully patched? What backend was it using >> when it hung? Did you get a backtrace of where it hung? > > I'm using libdb-4_5-4.5.20-94.17 from openSUSE 11.1 which is AFAIK fully > patched. > > I think this is related to modifications in connection.c because trouble > started after HEAD contained these changes. You still didn't answer most of these questions, or what kernel you're using. I ask about the full rebuild of OpenLDAP because the changes in the connection code changed the size of the connection struct, and I know it will fail without that rebuild. A backtrace of the hang would be useful for diagnosis, since so far neither Howard nor I can reproduce this. I'd also like to know the Linux kernel version, since some of the changes affect epoll (linux 2.6) specifically. I'm running a 2.6.18 kernel+patches currently. Also, what flags are you passing to gcc while building? -g? -O2? etc. I.e., are you putting optimizations into place. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 22 Jan '09

22 Jan '09

rlvcosta(a)yahoo.com wrote: > Quanah, > > I just used tcmalloc but I still with the same behavior. slapd doesn't > have limit for the cache and then it cannot run large databases. As a side comment, we have already documented that about 1 million entries is the practical limit for slapd on a 32 bit machine. Since 64 bit machines are so common today, making slapd perform well on a 32 bit machine is no longer a priority. Also, by design, tcmalloc doesn't release freed memory back to the OS, since it will most likely be needed again. It's normal for the slapd process size to never shrink. One thing you can check is to add a "database monitor" to your slapd configuration; one of the entries under cn=monitor will report the number of items in the back-bdb cache. Please provide this information here. -- -- 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#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 22 Jan '09

22 Jan '09

Quanah, I just used tcmalloc but I still with the same behavior. slapd doesn't have limit for the cache and then it cannot run large databases. My DB entrance is not large. One example is : dn: uid=1219843773896\2B554184XXXXXX,ou=REPOSITORY,ou=CONTENT,o=domain,c=country creationdate: 200808271329Z localelist: en,fr weblogin: +554184XXXXXX expirationdate: 200810161329Z profileid: 0 mail: +554184XXXXXX/type=PLMN@<domain> uid: 1219843773896+554184XXXXXX objectClass: commonuser objectClass: user accountStatus: 1 webpassword: 0000 cn: +554184XXXXXX optionvalues:: AAEAAAcBAgEAAQEBAQEBAAAAAQEBAAEBAQEAAQAAAAAAAAMAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== optionstates:: AAAAAAABAwAAAAAAAAABAAAAAQIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== isintercepted: FALSE dn: pnnumber=\2B554184XXXXXX,uid=1219843773896\2B554184XXXXXX,ou=REPOSITORY,ou =CONTENT,o=domain,c=country subpnid: 0 pntype: 2 pncaps: 7 objectClass: phoneinfo pnnumber: +554184XXXXXX dn: submxid=0,uid=1219843773896\2B554184XXXXXX,ou=REPOSITORY,ou=CONTENT,o=domain,c=country secretcode: 0000 fraudaccessnb: 0 mailMessageStore: ./Maildir maillogin: +554184XXXXXX/type=PLMN@<domain> objectClass: commonmailbox objectClass: courierinfo submxid: 0 mailQuota: 1048576 mailpassword: <secret> homeDirectory: /var/mms/mail/0/00/0000000000/0 See above I have 3 DN's. In 64 bits systems with more memory and small dn's this could be hidden but with the time all physical memory will be used. So, I made an ldapsearch as (searching a single DN): time ldapsearch -LLL -x -D "cn=admin,ou=CONTENT,o=domain,c=country" -w secret -b "ou=CONTENT,o=domain,c=country" -H ldap://10.142.15.42:389 'pnnumber=*'| egrep -e '^pnnumber*' |wc -l 1000003 real 6m56.321s user 0m25.617s sys 0m8.392s So just one of the 3 DNs this DB has. Since the filesize is : 1.9G dn2id.bdb 3.1G id2entry.bdb 29M maillogin.bdb 3.3M objectClass.bdb 28M pnnumber.bdb 1.3M submxid.bdb 84M uid.bdb I have part of size load into cache(only for pnnnumber). But slapd doesn't respect cache limits and load all into memory. It also never release it. The entrances are not large and caches in the order of 1000 entrances should not make slapd process stay with almost 1GB of memory. Also once it occupies this memory it never release anymore. I use lsof and the tcmalloc is being used. Regards, Rodrigo. --- On Thu, 1/22/09, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > From: Quanah Gibson-Mount <quanah(a)zimbra.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com, openldap-its(a)openldap.org > Date: Thursday, January 22, 2009, 4:04 PM > --On Thursday, January 22, 2009 10:01 AM -0800 Rodrigo Costa > <rlvcosta(a)yahoo.com> wrote: > > > Quanah, > > > > Just a correction about the man, it was incorrect > since my man was > > getting from cache(and so from 2.3 version). Now it is > ok. > > > > I would like a little more directions about how can be > compiled openldap > > 2.4.13 with tcmalloc. Just need to include a lib path? > Some configure > > parameter in openldap? > > I use tcmalloc myself, so basically you go and build > google-perf-tools, and then you preload the library before > starting slapd. I have a little startup script for slapd: > > #!/bin/bash > ulimit -n 32768 > ulimit -c unlimited > export LD_PRELOAD=/opt/zimbra/tcmalloc/lib/libtcmalloc.so > exec /opt/zimbra/openldap/sbin/slapd "$@" > > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and > collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by quanah＠zimbra.com 22 Jan '09

22 Jan '09

--On Thursday, January 22, 2009 10:01 AM -0800 Rodrigo Costa <rlvcosta(a)yahoo.com> wrote: > Quanah, > > Just a correction about the man, it was incorrect since my man was > getting from cache(and so from 2.3 version). Now it is ok. > > I would like a little more directions about how can be compiled openldap > 2.4.13 with tcmalloc. Just need to include a lib path? Some configure > parameter in openldap? I use tcmalloc myself, so basically you go and build google-perf-tools, and then you preload the library before starting slapd. I have a little startup script for slapd: #!/bin/bash ulimit -n 32768 ulimit -c unlimited export LD_PRELOAD=/opt/zimbra/tcmalloc/lib/libtcmalloc.so exec /opt/zimbra/openldap/sbin/slapd "$@" --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 22 Jan '09

22 Jan '09

Quanah, Just a correction about the man, it was incorrect since my man was getting from cache(and so from 2.3 version). Now it is ok. I would like a little more directions about how can be compiled openldap 2.4.13 with tcmalloc. Just need to include a lib path? Some configure parameter in openldap? Regards, Rodrigo. --- On Thu, 1/22/09, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > From: Quanah Gibson-Mount <quanah(a)zimbra.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com, openldap-its(a)openldap.org > Date: Thursday, January 22, 2009, 2:53 PM > --On Thursday, January 22, 2009 4:46 PM +0000 > rlvcosta(a)yahoo.com wrote: > > > [root@brtldp12 yum.repos.d]# ll > /usr/man/man8/slapd.8.gz > > -rw-r--r-- 1 root root 4392 Jan 22 03:28 > /usr/man/man8/slapd.8.gz > > > > [root@brtldp12 yum.repos.d]# ll > /usr/man/man5/slapd-bdb.5.gz > > -rw-r--r-- 1 root root 4089 Jan 22 03:28 > /usr/man/man5/slapd-bdb.5.gz > > > > I was expecting to find information about dncachesize > in slapd-bdb but > > there isn't nothing there. > > [build@build11 man5]$ grep dncachesize * > slapd-bdb.5:.BI dncachesize \ <integer> > slapd-hdb.5:.BI dncachesize \ <integer> > > It's documented for me... > > .BI dncachesize \ <integer> > Specify the maximum number of DNs in the in-memory DN > cache. The > default is twice the \fBcachesize\fP. Ideally this > cache should be > large enough to contain the DNs of every entry in the > database. > > You can also find it in the online manual pages: > > <http://www.openldap.org/software/man.cgi?query=slapd-bdb&apropos=0&sektion=…> > > > > > In any case slapd never respects memory limitation and > consumes it > > without boundaries. It also never releases any memory. > > > > Then after sometime the process cannot allocate more > memory and crashes. > > As Howard noted, you need to use an alternative memory > allocator than > glibc. Investigate horde or tcmalloc. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and > collaboration

1 0

Re: (ITS#5900) Problem to populate LDAP 2.4.12 with an Ldiff file on SUNBLADE
by hyc＠symas.com 22 Jan '09

22 Jan '09

fethi.tekitek(a)alcatel-lucent.com wrote: > Full_Name: Fathy Tekitek > Version: 2.4.12 > OS: Solaris 10 (rev 8) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.23.212.109) > > > Hi, > I try to populate the openldap 2.4.12 running with BerkeleyDB 4.7.25 using an > ldiff file > The first two entry are populate but It remains blocked > This problem is reproducible on SunBlade 100 servers but not in T5000, > SunBlade2500 and Ultra45 where it works OK. Make sure you have applied the patches to BDB 4.7.25 from the Oracle web site. This ITS will be closed. -- -- 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#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 22 Jan '09

22 Jan '09

rlvcosta(a)yahoo.com wrote: > Howard, > > I have the always the same DB_CONFIG file as below : > > set_cachesize 0 52428800 1 > > set_flags DB_LOG_AUTOREMOVE > > set_lg_regionmax 1048576 > set_lg_max 10485760 > set_lg_bsize 2097152 > > set_tmp_dir /var/tmp > > I just removed the comment lines so it fits better on screen. > > About versions I have : > > [root@brtldp12 yum.repos.d]# /usr/libexec/slapd -V > @(#) $OpenLDAP: slapd 2.4.13 (Jan 22 2009 02:28:12) $ > root@brtldp12:/root/openldap-2.4.13/servers/slapd > > [root@brtldp12 yum.repos.d]# db_verify -V > Berkeley DB 4.7.25: (May 15, 2008) > > About the man pages I have : > > [root@brtldp12 yum.repos.d]# ll /usr/man/man8/slapd.8.gz > -rw-r--r-- 1 root root 4392 Jan 22 03:28 /usr/man/man8/slapd.8.gz > > [root@brtldp12 yum.repos.d]# ll /usr/man/man5/slapd-bdb.5.gz > -rw-r--r-- 1 root root 4089 Jan 22 03:28 /usr/man/man5/slapd-bdb.5.gz > > I was expecting to find information about dncachesize in slapd-bdb but there isn't nothing there. According to CVS the documentation was added in August 2007. It's been online for quite a long time as well. http://www.openldap.org/software/man.cgi?query=slapd-bdb&sektion=5&apropos=… Another point is that the cache configurations are based on a specific number of items, and not on the size of each item in bytes. If you have particularly large entries or long DNs then you'll have greater memory use as well. -- -- 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#5860) slapd memeory leak under openldap 2.4
by quanah＠zimbra.com 22 Jan '09

22 Jan '09

--On Thursday, January 22, 2009 4:46 PM +0000 rlvcosta(a)yahoo.com wrote: > [root@brtldp12 yum.repos.d]# ll /usr/man/man8/slapd.8.gz > -rw-r--r-- 1 root root 4392 Jan 22 03:28 /usr/man/man8/slapd.8.gz > > [root@brtldp12 yum.repos.d]# ll /usr/man/man5/slapd-bdb.5.gz > -rw-r--r-- 1 root root 4089 Jan 22 03:28 /usr/man/man5/slapd-bdb.5.gz > > I was expecting to find information about dncachesize in slapd-bdb but > there isn't nothing there. [build@build11 man5]$ grep dncachesize * slapd-bdb.5:.BI dncachesize \ <integer> slapd-hdb.5:.BI dncachesize \ <integer> It's documented for me... .BI dncachesize \ <integer> Specify the maximum number of DNs in the in-memory DN cache. The default is twice the \fBcachesize\fP. Ideally this cache should be large enough to contain the DNs of every entry in the database. You can also find it in the online manual pages: <http://www.openldap.org/software/man.cgi?query=slapd-bdb&apropos=0&sektion=…> > > In any case slapd never respects memory limitation and consumes it > without boundaries. It also never releases any memory. > > Then after sometime the process cannot allocate more memory and crashes. As Howard noted, you need to use an alternative memory allocator than glibc. Investigate horde or tcmalloc. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 22 Jan '09

22 Jan '09

Howard, I have the always the same DB_CONFIG file as below : set_cachesize 0 52428800 1 set_flags DB_LOG_AUTOREMOVE set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 set_tmp_dir /var/tmp I just removed the comment lines so it fits better on screen. About versions I have : [root@brtldp12 yum.repos.d]# /usr/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.13 (Jan 22 2009 02:28:12) $ root@brtldp12:/root/openldap-2.4.13/servers/slapd [root@brtldp12 yum.repos.d]# db_verify -V Berkeley DB 4.7.25: (May 15, 2008) About the man pages I have : [root@brtldp12 yum.repos.d]# ll /usr/man/man8/slapd.8.gz -rw-r--r-- 1 root root 4392 Jan 22 03:28 /usr/man/man8/slapd.8.gz [root@brtldp12 yum.repos.d]# ll /usr/man/man5/slapd-bdb.5.gz -rw-r--r-- 1 root root 4089 Jan 22 03:28 /usr/man/man5/slapd-bdb.5.gz I was expecting to find information about dncachesize in slapd-bdb but there isn't nothing there. Where at config.c I have : "( OLcfgDbAt:1.5 NAME 'olcDbDirtyRead' " "DESC 'Allow reads of uncommitted data' " "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL }, { "dncachesize", "size", 2, 2, 0, ARG_UINT|ARG_OFFSET, (void *)offsetof(struct bdb_info, bi_cache.c_eimax), "( OLcfgDbAt:1.12 NAME 'olcDbDNcacheSize' " "DESC 'DN cache size' " "SYNTAX OMsInteger SINGLE-VALUE )", NULL, NULL } So the dncachesize is supposed to be in the code. In any case slapd never respects memory limitation and consumes it without boundaries. It also never releases any memory. Then after sometime the process cannot allocate more memory and crashes. Best Regards, Rodrigo. --- On Thu, 1/22/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)openldap.org > Date: Thursday, January 22, 2009, 1:35 PM > rlvcosta(a)yahoo.com wrote: > > > See that I have 2 DBs and in each DB area in > slapd.conf, read without error by slapd as seen above, I > have the cachesize, idlcachesize and dncachesize specified > with small values just to monitor the memory usage by slapd. > > > > Unfortunately even with this configuration I still > having slapd consuming memory without release it. So if a > new entrance is queried by some LDAP client, slapd will > consume more memory. Since my DB dn's are bigger than > 3GB then soon or later the slapd will crash. > > > > See my DB information : > > > > 7.2G dn2id.bdb > > 12G id2entry.bdb > > 110M maillogin.bdb > > 3.3M objectClass.bdb > > 108M pnnumber.bdb > > 1.3M submxid.bdb > > 323M uid.bdb > > > > See my dn2id is much bigger than yours and maybe you > just did not saw this > issue happenig since your dn can be loaded in your memory > and you in a 64 bits > environment can use more than 3GB per process. > > > > But in any case looks like there is a problem in slapd > that do not respect > the cache limitations imposed. > > > > In this way we cannot use slapd for large databases. > Please see my > configuration above and let me know if a made a mistake(I > hope so) since > dncachesize is not documented at man pages. > > You're mistaken, dncachesize is in the 2.4 manpages. > You seem to not be > reading the documentation that came with the software > release you're using. > > > Just as example, with the DB I loaded for tests with 1 > million entrances, with the cache sizes definitions as in > the slapd.conf described above and making a ldapsearch on > all entrances from the CONTENT DB, in the end I have : > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM > TIME+ COMMAND > > 3189 ldap 15 0 842m 724m 67m S 99 6.1 > 7:00.48 slapd > > > > See the slapd process already consumed 842m and I just > read 1 million entrances, even dncachesize is defined to be > 1000. > > > > I do not see anyway to control the memory usage by > slapd. > > > > Is this "disrespect" to slapd.conf > directives a possible problem? > > Looks like slapd is behaving normally so far, though > it's hard to tell without > also seeing your DB_CONFIG settings. Test again with your > full database and > report the results. > > -- > -- 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#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 22 Jan '09

22 Jan '09

hyc(a)symas.com wrote: > rlvcosta(a)yahoo.com wrote: > >> See that I have 2 DBs and in each DB area in slapd.conf, read without error by slapd as seen above, I have the cachesize, idlcachesize and dncachesize specified with small values just to monitor the memory usage by slapd. >> >> Unfortunately even with this configuration I still having slapd consuming memory without release it. So if a new entrance is queried by some LDAP client, slapd will consume more memory. Since my DB dn's are bigger than 3GB then soon or later the slapd will crash. >> >> See my DB information : >> >> 7.2G dn2id.bdb >> 12G id2entry.bdb >> 110M maillogin.bdb >> 3.3M objectClass.bdb >> 108M pnnumber.bdb >> 1.3M submxid.bdb >> 323M uid.bdb > You're mistaken, dncachesize is in the 2.4 manpages. You seem to not be > reading the documentation that came with the software release you're using. > >> Just as example, with the DB I loaded for tests with 1 million entrances, with the cache sizes definitions as in the slapd.conf described above and making a ldapsearch on all entrances from the CONTENT DB, in the end I have : >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 3189 ldap 15 0 842m 724m 67m S 99 6.1 7:00.48 slapd >> >> See the slapd process already consumed 842m and I just read 1 million entrances, even dncachesize is defined to be 1000. >> >> I do not see anyway to control the memory usage by slapd. >> >> Is this "disrespect" to slapd.conf directives a possible problem? > > Looks like slapd is behaving normally so far, though it's hard to tell without > also seeing your DB_CONFIG settings. Test again with your full database and > report the results. > I'll note that this is a pathological use case for glibc malloc. With a cache of only 1000 entries, searching 1 million entries will result in several million malloc/free calls which will fragment the heap, and that will cause results like what you're seeing. You'll have better luck with hoard or tcmalloc. -- -- 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: Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by hyc＠symas.com 22 Jan '09

22 Jan '09

adrien.futschik(a)atosorigin.com wrote: > I Think I found the problem. > > I have to confirm this, but the "olcSpSessionlog" parameter doesn't seem > to be necessary. > I made a mistake in my configuration. I used "refreshOnly" mode for the backend and with "refreshOnly", consumer isn't aware when a provider deletes an entry. So I understood at least. No. Replication is supposed to work regardless of mode, refreshOnly / refreshAndPersist should yield identical results. > Here is a extract from the documentation about syncrepl : "Also as a > consequence of the search filter used in the syncrepl specification, it is possible for a modification to remove an entry from the replication scope even though the entry has not been deleted on the provider. Logically the entry must be deleted on the consumer but in refreshOnly mode the provider cannot detect and propagate this change without the use of the session log." The above text is correct, but it is talking about partial replication where the syncrepl search filter causes only a subset of the entries to be replicated. That does not apply to your case because you haven't set any special filter in your syncrepl config. > So I guess this was not a bug, but a mistake in the documentation : > http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master > > Can anyone confirm ? There is still a bug here. -- -- 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#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 22 Jan '09

22 Jan '09

rlvcosta(a)yahoo.com wrote: > See that I have 2 DBs and in each DB area in slapd.conf, read without error by slapd as seen above, I have the cachesize, idlcachesize and dncachesize specified with small values just to monitor the memory usage by slapd. > > Unfortunately even with this configuration I still having slapd consuming memory without release it. So if a new entrance is queried by some LDAP client, slapd will consume more memory. Since my DB dn's are bigger than 3GB then soon or later the slapd will crash. > > See my DB information : > > 7.2G dn2id.bdb > 12G id2entry.bdb > 110M maillogin.bdb > 3.3M objectClass.bdb > 108M pnnumber.bdb > 1.3M submxid.bdb > 323M uid.bdb > > See my dn2id is much bigger than yours and maybe you just did not saw this issue happenig since your dn can be loaded in your memory and you in a 64 bits environment can use more than 3GB per process. > > But in any case looks like there is a problem in slapd that do not respect the cache limitations imposed. > > In this way we cannot use slapd for large databases. Please see my configuration above and let me know if a made a mistake(I hope so) since dncachesize is not documented at man pages. You're mistaken, dncachesize is in the 2.4 manpages. You seem to not be reading the documentation that came with the software release you're using. > Just as example, with the DB I loaded for tests with 1 million entrances, with the cache sizes definitions as in the slapd.conf described above and making a ldapsearch on all entrances from the CONTENT DB, in the end I have : > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 3189 ldap 15 0 842m 724m 67m S 99 6.1 7:00.48 slapd > > See the slapd process already consumed 842m and I just read 1 million entrances, even dncachesize is defined to be 1000. > > I do not see anyway to control the memory usage by slapd. > > Is this "disrespect" to slapd.conf directives a possible problem? Looks like slapd is behaving normally so far, though it's hard to tell without also seeing your DB_CONFIG settings. Test again with your full database and report the results. -- -- 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: Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by ghenry＠OpenLDAP.org 22 Jan '09

22 Jan '09

> So I guess this was not a bug, but a mistake in the documentation : > http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master > > Can anyone confirm ? Yes, you are correct, apologies. Ando fixed this in test050: ----------- 1.14 Sun Nov 16 22:06:30 2008 UTC; 2 months ago by ando Changed since 1.13: +28 -10 lines Diffs to 1.13 (colored diff) add indexes when supported; syncrepl on configuration should always be refreshAndPersist ----------- and I missed it for updating the docs. The update to the guide will be in the next release, 2.4.14 I'll close this ITS now. Thanks! -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 22 Jan '09

22 Jan '09

Quanah, I follow your recommendation and compiled the Berkeley Db 4.7.25NC and openldap 2.4.13. After that load my LDIF file to have 1million entraces in my DB just to test the dncachesize control. During my initialization I have : module back_bdb.la: null module registered line 29 (moduleload back_monitor.la) loaded module back_monitor.la module back_monitor.la: null module registered line 74 (database bdb) line 75 (suffix "ou=CONTENT,o=alcatel,c=fr") line 76 (rootdn "cn=admin,ou=CONTENT,o=alcatel,c=fr") line 80 (rootpw ***) line 86 (directory /var/openldap-data/bdb1) line 89 (index userid,pnnumber,submxid,maillogin,abookaliasid eq,pres) index uid 0x0006 index pnnumber 0x0006 index submxid 0x0006 index maillogin 0x0006 index abookaliasid 0x0006 line 90 (index objectClass eq) index objectClass 0x0004 line 93 (cachesize 1000) line 94 (idlcachesize 1000) line 95 (dncachesize 1000) line 105 (database bdb) line 106 (suffix "ou=INDEXES,o=alcatel,c=fr") line 107 (rootdn "cn=admin,ou=INDEXES,o=alcatel,c=fr") line 111 (rootpw ***) line 114 (directory /var/openldap-data/bdb2) line 117 (index weblogin,maillogin,mail,pnnumber eq,pres) index weblogin 0x0006 index maillogin 0x0006 index mail 0x0006 index pnnumber 0x0006 line 118 (index profileid,loginname eq,pres) index profileid 0x0006 index loginname 0x0006 line 119 (index objectClass eq) index objectClass 0x0004 line 122 (cachesize 1000) line 123 (idlcachesize 1000) line 124 (dncachesize 1000) line 129 (database monitor) slapd starting See that I have 2 DBs and in each DB area in slapd.conf, read without error by slapd as seen above, I have the cachesize, idlcachesize and dncachesize specified with small values just to monitor the memory usage by slapd. Unfortunately even with this configuration I still having slapd consuming memory without release it. So if a new entrance is queried by some LDAP client, slapd will consume more memory. Since my DB dn's are bigger than 3GB then soon or later the slapd will crash. See my DB information : 7.2G dn2id.bdb 12G id2entry.bdb 110M maillogin.bdb 3.3M objectClass.bdb 108M pnnumber.bdb 1.3M submxid.bdb 323M uid.bdb See my dn2id is much bigger than yours and maybe you just did not saw this issue happenig since your dn can be loaded in your memory and you in a 64 bits environment can use more than 3GB per process. But in any case looks like there is a problem in slapd that do not respect the cache limitations imposed. In this way we cannot use slapd for large databases. Please see my configuration above and let me know if a made a mistake(I hope so) since dncachesize is not documented at man pages. Just as example, with the DB I loaded for tests with 1 million entrances, with the cache sizes definitions as in the slapd.conf described above and making a ldapsearch on all entrances from the CONTENT DB, in the end I have : PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3189 ldap 15 0 842m 724m 67m S 99 6.1 7:00.48 slapd See the slapd process already consumed 842m and I just read 1 million entrances, even dncachesize is defined to be 1000. I do not see anyway to control the memory usage by slapd. Is this "disrespect" to slapd.conf directives a possible problem? I hope there is a configuration problem with my slapd.conf where this could be work around. Regards, Rodrigo. --- On Wed, 1/21/09, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > From: Quanah Gibson-Mount <quanah(a)zimbra.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com, openldap-its(a)openldap.org > Date: Wednesday, January 21, 2009, 8:30 PM > --On Wednesday, January 21, 2009 12:49 PM -0800 Rodrigo > Costa <rlvcosta(a)yahoo.com> wrote: > > > Quanah, > > > > That's is exactly the point. My system is a 32 > bits and with 64 bits if > > there are enough physical memory available even slapd > cache grows without > > never release it will be difficult(or very long) to > cache enough > > entrances before system consumes all memory. > > > > With the 32 bits 3GB maximum, depend on OS too, this > issue appears more > > often. My impression is if you ldapsearch all DB in a > 32 bits HW/OS slapd > > will consume all possible memory unless to keep > boundaries for its > > cache(erase and overwrite). > > As I noted, in 2.3, you cannot constrain the DN cachesize. > You can do this with OL 2.4. You need to try a current > RE2.4 release, and set the dncachesize. There was no dn > cache at all in OL 2.1. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and > collaboration

1 0

Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by adrien.futschik＠atosorigin.com 22 Jan '09

22 Jan '09

I Think I found the problem. I have to confirm this, but the "olcSpSessionlog" parameter doesn't seem to be necessary. I made a mistake in my configuration. I used "refreshOnly" mode for the backend and with "refreshOnly", consumer isn't aware when a provider deletes an entry. So I understood at least. Here is a extract from the documentation about syncrepl : "Also as a consequence of the search filter used in the syncrepl specification, it is possible for a modification to remove an entry from the replication scope even though the entry has not been deleted on the provider. Logically the entry must be deleted on the consumer but in refreshOnly mode the provider cannot detect and propagate this change without the use of the session log." Therefore I changed "refreshOnly" for "refreshAndPersist", I removed the "olcSpSessionlog" parameter, and everything seems to be working fine. At least, deletes are correctly replicated to the second master. Here is the final configuration I am using : m1 -config : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:< file://$CONFIGPWF m2 - config : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 2 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:< file://$CONFIGPWF m1 - syncprov : dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE m2 - syncrepl : dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE m1 - schema : include: file://$ABS_SCHEMADIR/core.ldif include: file://$ABS_SCHEMADIR/cosine.ldif include: file://$ABS_SCHEMADIR/inetorgperson.ldif include: file://$ABS_SCHEMADIR/openldap.ldif include: file://$ABS_SCHEMADIR/nis.ldif m1 - backend : dn: olcDatabase={1}$BACKEND,cn=config objectClass: olcDatabaseConfig objectClass: olc${BACKEND}Config olcDatabase: {1}$BACKEND olcSuffix: $BASEDN olcDbDirectory: ./openldap-data olcRootDN: $MANAGERDN olcRootPW: $PASSWD olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshAndPersist interval=$INTERVAL retry="5 5 300 5" timeout=3 olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshAndPersist interval=$INTERVAL retry="5 5 300 5" timeout=3 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov So I guess this was not a bug, but a mistake in the documentation : http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master Can anyone confirm ? Adrien Futschik

1 0

Re: (ITS#5883) [PATCH] syncrepl test enhancements
by hyc＠symas.com 22 Jan '09

22 Jan '09

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: HEAD > OS: irrelevant > URL: https://www.nbcs.rutgers.edu/~richton/syncrepl-modrdn-tests.patch > Submission from: (NULL) (67.85.181.229) > > > Per http://www.openldap.org/lists/openldap-devel/200812/msg00004.html these > patches enhance tests to detect ITS#5809-like behavior. > > The actual test changes are at the address linked to this report. They should > apply clean to HEAD and can be used immediately with, for example, back-ldif. I > note that I wasn't able to reproduce a failure under test018; if anybody can > suggest a different test there, that'd be great, or perhaps the stopping and > starting somehow masks the condition? > > While verifying the tests, I noticed that some backends (such as back-bdb) were > failing because the consumer and provider returned the attributes in a different > order. Since attribute ordering isn't guaranteed, I viewed this as a test > failure rather than a slapd failure, and used the back-ndb gawk acfilter.sh to > work around this. In the end I just made it apply to all backends: Since we want to minimize the dependency on gawk, I took a look at the ordering failure. It occurs because the syncrepl consumer internally processes renames before it processes modifies. As such, just changing the test script to execute in this order seems to avoid the problem. > > https://www.nbcs.rutgers.edu/~richton/acfilter.patch > > but we'll probably want to discuss this on -devel: it adds a gawk dependency to > the tests. > > With the acfilter.sh sorting enabled, I found three tests that don't filter the > original data prior to ldapsearch comparison. I added these filters in: > > https://www.nbcs.rutgers.edu/~richton/openldap-testflt.patch Sounds like it should be harmless to include this patch... > > We all know that nothing's free -- a couple extra commands in the name of bug > coverage is probably worth it -- but the gawk dependency may be troublesome. > Anyway, do what you will...I consider these pretty trivial, so: > > These patch files are derived from OpenLDAP Software. All of the modifications > to OpenLDAP Software represented in these patches were developed by Aaron > Richton<richton(a)nbcs.rutgers.edu>. I have not assigned rights and/or interest > in this work to any party. > > I, Aaron Richton, hereby place these modifications to OpenLDAP Software (and > only these modifications) into the public domain. Hence, these modifications may > be freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > > -- -- 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#5901) modrdn syncing busted
by quanah＠zimbra.com 22 Jan '09

22 Jan '09

Full_Name: Quanah Gibson-Mount Version: 2.4.13 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) As noted in a post to the bugs list: Hello, I have configured a central OpenLDAP, using Debian Etch, version: slapd 2.3.30-5+etch1, which is also a sync provider. Another Debian Etch box uses the sync: syncrepl rid=123 provider=ldap://example.com type=refreshAndPersist retry="5,2,30,2,60,+" interval=00:01:00:00 searchbase="basedn" filter="(objectClass=*)" scope=sub attrs="*,+" sizelimit=0 timelimit=0 schemachecking=on bindmethod=simple binddn="someDN" credentials="somePwd" starttls=critical This works fine, but moddn fails: for testing purpose I ldapadd : dn: c=testtt,ou=basedn c: testtt objectClass: country then: ldapmodrdn -r 'c=testtt,ou=basedn' 'c=testww' It works on the sync provider (schemacheck on) and the result is: dn: c=testww,ou=basedn objectClass: country c: testww But on the sync consumer: : syncrepl_entry: c=testww,ou=basedn : Entry (c=testww,ou=basedn attribute 'c' cannot have multiple values : entry failed schema check: attribute 'c' cannot have multiple values : null_callback : error code 0x13 : syncrepl_entry: be_modrdn (19) The testtt entry is still present on the secondary box. If I delete "testww" on the sync provider, the "testt" entry in the consumere is deleted. As noted by Howard in follow up: Actually... this would have worked correctly in 2.4.11 and 2.4.12. In 2.4.13 I reverted back to the 2.3 behavior due to other concerns, so this will probably fail again. And the test script does a rename on an entry whose distinguished attribute is multivalued, so it doesn't catch this case. I think we'll have to revisit this patch for 2.4.14 and add an additional rename test to test017 and test018.

1 0

Re: (ITS#5701) connection.c asserting during test008
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Saturday, September 20, 2008 8:03 PM +0000 richton(a)nbcs.rutgers.edu wrote: > On Sat, 20 Sep 2008, Pierangelo Masarati wrote: > Connection code has been reworked in current RE24 and may have resolved this issue. Can you please test? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5880) back-bdb segfault
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Saturday, January 17, 2009 3:13 AM +0000 quanah(a)zimbra.com wrote: > I'm just warning that current RE24 is not expected to be at all stable. In fact, I note that both your reports are against RE24 CVS checkouts, and not a release. Please reproduce in a release (I expect it will still occur there), rather than unstable CVS. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 12:49 PM -0800 Rodrigo Costa <rlvcosta(a)yahoo.com> wrote: > Quanah, > > That's is exactly the point. My system is a 32 bits and with 64 bits if > there are enough physical memory available even slapd cache grows without > never release it will be difficult(or very long) to cache enough > entrances before system consumes all memory. > > With the 32 bits 3GB maximum, depend on OS too, this issue appears more > often. My impression is if you ldapsearch all DB in a 32 bits HW/OS slapd > will consume all possible memory unless to keep boundaries for its > cache(erase and overwrite). As I noted, in 2.3, you cannot constrain the DN cachesize. You can do this with OL 2.4. You need to try a current RE2.4 release, and set the dncachesize. There was no dn cache at all in OL 2.1. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 21 Jan '09

21 Jan '09

Quanah, That's is exactly the point. My system is a 32 bits and with 64 bits if there are enough physical memory available even slapd cache grows without never release it will be difficult(or very long) to cache enough entrances before system consumes all memory. With the 32 bits 3GB maximum, depend on OS too, this issue appears more often. My impression is if you ldapsearch all DB in a 32 bits HW/OS slapd will consume all possible memory unless to keep boundaries for its cache(erase and overwrite). In 64 bits with a lot of memory this will be more difficult to happen but eventually will happen if the logic is the same. I was wondering if in a sittuation where this cache memory issue would appear, like ldapsearch, if there is a feature in openldap where it would guarantee the cache boundaries and the reutilization of the space after the limits are reached. Looks like even with the slapd.conf configurations it doesn't keeps its limits. Regards, Rodrigo. --- On Wed, 1/21/09, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > From: Quanah Gibson-Mount <quanah(a)zimbra.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com, openldap-its(a)openldap.org > Date: Wednesday, January 21, 2009, 6:41 PM > --On Wednesday, January 21, 2009 12:23 PM -0800 Rodrigo > Costa <rlvcosta(a)yahoo.com> wrote: > > > Quanah, > > > > My initial attempt was using openldap2.4.11 since this > is the stable > > version. At this version Berkeley DB 4.7 isn't > supported and then I used > > the BDB 4.6 with all patches. > > I hardly consider 2.4.11 stable, regardless of what the tag > is. I would advise trying something more current (such as > 2.4.13). And with BDB 4.7 + patches. > > > At this configuration, having the DB_CONFIG setup for > 50MB, and even > > having the idlcache and cache sizes defined I continue > to see the memory > > being allocated and never released by slapd. > > What about dncachesize as well? > > > 2.3.27-8.el5_2.4 where the CentOS5.4 uses a built-in > backend library for > > BDB4.4. > > If you are looking for stability, I would hardly go with > the crappy release CentOS ships. The final 2.3 release was > 2.3.43. Use it instead if you want to use 2.3. > > Also, are you on a 32 or 64-bit system? I certainly have > no problems going over 3GB on my 64-bit systems. > > For example: > [zimbra@ldap openldap-data]$ du -c -h *.bdb > 1.1G cn.bdb > 564M displayName.bdb > 702M dn2id.bdb > 158M entryCSN.bdb > 122M entryUUID.bdb > 335M givenName.bdb > 6.5G id2entry.bdb > 1.1G mail.bdb > 5.5M objectClass.bdb > 855M sn.bdb > 121M uid.bdb > 8.0K zimbraDomainName.bdb > 122M zimbraId.bdb > 20K zimbraMailAlias.bdb > 1.1G zimbraMailDeliveryAddress.bdb > 2.1M zimbraMailForwardingAddress.bdb > 3.1M zimbraMailTransport.bdb > 8.0K zimbraVirtualHostname.bdb > 8.0K zimbraVirtualIPAddress.bdb > 13G total > > > DB is 13GB in size. > > [zimbra@ldap openldap-data]$ cat DB_CONFIG > set_cachesize 8 0 2 > set_lg_regionmax 262144 > set_lg_bsize 2097152 > set_lk_max_locks 1500 > set_flags DB_LOG_AUTOREMOVE > set_lg_dir /var/log/zimbra-ldap-journals > > Process size: > > 8447 zimbra 17 0 9.9g 8.9g 8.1g S 34 57.5 39:20.57 > slapd > > > Using OpenLDAP 2.3.42. > > > --Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and > collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 12:23 PM -0800 Rodrigo Costa <rlvcosta(a)yahoo.com> wrote: > Quanah, > > My initial attempt was using openldap2.4.11 since this is the stable > version. At this version Berkeley DB 4.7 isn't supported and then I used > the BDB 4.6 with all patches. I hardly consider 2.4.11 stable, regardless of what the tag is. I would advise trying something more current (such as 2.4.13). And with BDB 4.7 + patches. > At this configuration, having the DB_CONFIG setup for 50MB, and even > having the idlcache and cache sizes defined I continue to see the memory > being allocated and never released by slapd. What about dncachesize as well? > 2.3.27-8.el5_2.4 where the CentOS5.4 uses a built-in backend library for > BDB4.4. If you are looking for stability, I would hardly go with the crappy release CentOS ships. The final 2.3 release was 2.3.43. Use it instead if you want to use 2.3. Also, are you on a 32 or 64-bit system? I certainly have no problems going over 3GB on my 64-bit systems. For example: [zimbra@ldap openldap-data]$ du -c -h *.bdb 1.1G cn.bdb 564M displayName.bdb 702M dn2id.bdb 158M entryCSN.bdb 122M entryUUID.bdb 335M givenName.bdb 6.5G id2entry.bdb 1.1G mail.bdb 5.5M objectClass.bdb 855M sn.bdb 121M uid.bdb 8.0K zimbraDomainName.bdb 122M zimbraId.bdb 20K zimbraMailAlias.bdb 1.1G zimbraMailDeliveryAddress.bdb 2.1M zimbraMailForwardingAddress.bdb 3.1M zimbraMailTransport.bdb 8.0K zimbraVirtualHostname.bdb 8.0K zimbraVirtualIPAddress.bdb 13G total DB is 13GB in size. [zimbra@ldap openldap-data]$ cat DB_CONFIG set_cachesize 8 0 2 set_lg_regionmax 262144 set_lg_bsize 2097152 set_lk_max_locks 1500 set_flags DB_LOG_AUTOREMOVE set_lg_dir /var/log/zimbra-ldap-journals Process size: 8447 zimbra 17 0 9.9g 8.9g 8.1g S 34 57.5 39:20.57 slapd Using OpenLDAP 2.3.42. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 21 Jan '09

21 Jan '09

Quanah, My initial attempt was using openldap2.4.11 since this is the stable version. At this version Berkeley DB 4.7 isn't supported and then I used the BDB 4.6 with all patches. At this configuration, having the DB_CONFIG setup for 50MB, and even having the idlcache and cache sizes defined I continue to see the memory being allocated and never released by slapd. Now I tried to evolve my OS to CentOS5.2 and then see if it could be an issue with my compilation using a community compiled openldap version that could have syncrepl available. Based in my issues I'm not using syncrepl at this time since I'm trying to check a stable sittuation for my DB. What I'm observing is that under openldap version 2.3 and 2.4 if I have a DB, at least with BDB, that could be searched and generate indexes bigger than 3GB(max OS memory space per process), the search will make slapd load all indexes in memory and never release them. This make that openldap would not be used for DBs which size would become bigger than 3GB. What would be the major part of cases. Once a DB entrance is searched, it is loaded into memory and never more released. So, for example, if I made several binds to the same entrance in DB, slapd never allocates more memory and uses the already cached entrance. But if I search for different entrances in DB, slapd always cache in memory and continues to do it until it reaches the 3GB barrier and then process cannot allocate more memory. slapd never release cache memory, respect the default idlcachesize and cachesize that is 1000, or even release cache memory. So if there is not ldapsearch for a backup, that could speed this behavior, with the time if the queries are done randomly at certain time the cache will become of size 3GB and no more memory can be allocated. My actual version now is: 2.3.27-8.el5_2.4 where the CentOS5.4 uses a built-in backend library for BDB4.4. My DB_CONFIG is(without comments) : set_cachesize 0 52428800 1 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 set_tmp_dir /var/tmp And the slapd.conf I included(the indexes always existed) : # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/openldap-data/bdb1 # Indices to maintain for this database index userid,pnnumber,submxid,maillogin,abookaliasid eq,pres index objectClass eq #Cache values cachesize 1000 idlcachesize 1000 This issue, by other ITSs, appear to exist before. Not sure if this is really a configuration problem. Running slapd with -d 64 showed the cachesize and idlcachesize did not return any complain. Please let me know if you have some idea about this problem. I will try to use the not yet stable 2.4.13 but I would like to have your feedback if this could really be caused by other problem or even if in openldap 2.4.13 there are some detection/solution for this kind of issue. Regards, Rodrigo. --- On Wed, 1/21/09, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > From: Quanah Gibson-Mount <quanah(a)zimbra.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com, openldap-its(a)openldap.org > Date: Wednesday, January 21, 2009, 5:57 PM > --On Tuesday, January 20, 2009 12:07 AM +0000 > rlvcosta(a)yahoo.com wrote: > > > Pierangelo, > > > > Executing some test I'm not sure anymore if this > is really a memory > > leakage or if some cache issue. > > > > I decided to install CentOS5.2 where I could have > OpenLdap 2.3.27 > > compiled by the distribution and then execute more > tests to check if some > > library in RHEL4 would be causing some problem. > > > > I then use a similar slapd.conf as in my original > e-mail just without > > explicitly define an size for cache and idlcache > there. My DB_CONFIG file > > has a cache defined as 50MB what is respected. > > > > Looking at some other ITS I found the ITS#3938 what I > believe is very > > similar to my problem. > > > > I still have a DB with 3882998 entrances and where the > DB files at disk > > is around 15GB. My machine has 12GB of memory where > for sure all the DB > > cannot be cached into memory. > > > > In any case what is happening is that every time a > transaction is done > > with OpenLdap, even a distribution formal compilation, > the cache > > continues to grow until consumes all memory. If the DB > is bigger than > > machine memory then soon or later a memory out of > range will happen. > > > > The cache is never release by OpenLdap and then if a > sequential search is > > done and since DB is bigger than memory we can speed > up the problem. > > I would suggest you use OpenLDAP 2.4, and set the > slapd.conf cachesize, > idlcachesize, and dncachesize. I would also review your > settings for > DB_CONFIG, and use a newer BDB version with OpenLDAP 2.4 > (i.e., BDB 4.7 > with all 3 patches). See if that helps resolve the issue > you face. In > OpenLDAP 2.3, there is no way to control the dncachesize. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and > collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Tuesday, January 20, 2009 12:07 AM +0000 rlvcosta(a)yahoo.com wrote: > Pierangelo, > > Executing some test I'm not sure anymore if this is really a memory > leakage or if some cache issue. > > I decided to install CentOS5.2 where I could have OpenLdap 2.3.27 > compiled by the distribution and then execute more tests to check if some > library in RHEL4 would be causing some problem. > > I then use a similar slapd.conf as in my original e-mail just without > explicitly define an size for cache and idlcache there. My DB_CONFIG file > has a cache defined as 50MB what is respected. > > Looking at some other ITS I found the ITS#3938 what I believe is very > similar to my problem. > > I still have a DB with 3882998 entrances and where the DB files at disk > is around 15GB. My machine has 12GB of memory where for sure all the DB > cannot be cached into memory. > > In any case what is happening is that every time a transaction is done > with OpenLdap, even a distribution formal compilation, the cache > continues to grow until consumes all memory. If the DB is bigger than > machine memory then soon or later a memory out of range will happen. > > The cache is never release by OpenLdap and then if a sequential search is > done and since DB is bigger than memory we can speed up the problem. I would suggest you use OpenLDAP 2.4, and set the slapd.conf cachesize, idlcachesize, and dncachesize. I would also review your settings for DB_CONFIG, and use a newer BDB version with OpenLDAP 2.4 (i.e., BDB 4.7 with all 3 patches). See if that helps resolve the issue you face. In OpenLDAP 2.3, there is no way to control the dncachesize. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5900) Problem to populate LDAP 2.4.12 with an Ldiff file on SUNBLADE
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 6:41 PM +0000 fethi.tekitek(a)alcatel-lucent.com wrote: > Full_Name: Fathy Tekitek > Version: 2.4.12 > OS: Solaris 10 (rev 8) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.23.212.109) > > > Hi, > I try to populate the openldap 2.4.12 running with BerkeleyDB 4.7.25 > using an ldiff file > The first two entry are populate but It remains blocked > This problem is reproducible on SunBlade 100 servers but not in T5000, > SunBlade2500 and Ultra45 where it works OK. > I can enter the content of this file one bye one but all in the ldiff file > "/export/home/build26/openldap/bin/ldapadd -d 1 -H "ldaps://sunval233 " > -x -D "cn=root,dc=alu,dc=com" -f > /export/home/build26/CSA/data/installation/ngsecPopulate.ldif -w newuser1" Usage questions should generally be directed to openldap-software(a)openldap.org. I will note that (a) There are 3 patches now for BDB 4.7, make sure you are using them all, and (b) if your database is stored in NFS, that is not supported. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 2:35 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > I'm using libdb-4_5-4.5.20-94.17 from openSUSE 11.1 which is AFAIK fully > patched. > > The interesting fact is that HEAD currently hangs all the time in > test008. RE24 with your recent changes now fails as described in > test039. Before these changes RE24 just worked fine. > > I think this is related to modifications in connection.c because trouble > started after HEAD contained these changes. All tests pass for me with current RE24 and HEAD. What Linux kernel are you using? The RE24 changes to the connection code are the same as what are in HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5900) Problem to populate LDAP 2.4.12 with an Ldiff file on SUNBLADE
by fethi.tekitek＠alcatel-lucent.com 21 Jan '09

21 Jan '09

Full_Name: Fathy Tekitek Version: 2.4.12 OS: Solaris 10 (rev 8) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.23.212.109) Hi, I try to populate the openldap 2.4.12 running with BerkeleyDB 4.7.25 using an ldiff file The first two entry are populate but It remains blocked This problem is reproducible on SunBlade 100 servers but not in T5000, SunBlade2500 and Ultra45 where it works OK. I can enter the content of this file one bye one but all in the ldiff file "/export/home/build26/openldap/bin/ldapadd -d 1 -H "ldaps://sunval233 " -x -D "cn=root,dc=alu,dc=com" -f /export/home/build26/CSA/data/installation/ngsecPopulate.ldif -w newuser1" here the ldap traces ldap_url_parse_ext(ldaps://sunval233) ldap_create ldap_url_parse_ext(ldaps://sunval233:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP sunval233:636 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying 10.0.0.233:636 ldap_pvt_connect: fd: 4 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 0, subject: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC, issuer: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC TLS certificate verification: depth: 0, err: 0, subject: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC/CN=sunval233, issuer: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 43 bytes to sd 4 ldap_result ld 90c48 msgid 1 wait4msg ld 90c48 msgid 1 (infinite timeout) wait4msg continue ld 90c48 msgid 1 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 1 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select read1msg: ld 90c48 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 90c48 msgid 1 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 90c48 0 new referrals read1msg: mark request completed, ld 90c48 msgid 1 request done: ld 90c48 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree adding new entry "dc=alu,dc=com" ldap_add_ext ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 101 bytes to sd 4 ldap_result ld 90c48 msgid 2 wait4msg ld 90c48 msgid 2 (timeout 100000 usec) wait4msg continue ld 90c48 msgid 2 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 2 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select ldap_result ld 90c48 msgid 2 wait4msg ld 90c48 msgid 2 (timeout 100000 usec) wait4msg continue ld 90c48 msgid 2 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 2 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select ldap_result ld 90c48 msgid 2 wait4msg ld 90c48 msgid 2 (timeout 100000 usec) wait4msg continue ld 90c48 msgid 2 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 2 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select ^C #

1 0

Re: (ITS#5899) make fails on AIX5.3
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 5:12 PM +0000 masterson.andrew(a)gmail.com wrote: > Full_Name: Andrew > Version: 2.4.11 > OS: AIX5.3 64 bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.98.237.232) > > > configure runs > > CPPFLAGS=-I/usr/local/BerkeleyDB.4.7/include > LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib ./configure --enable-ipv6 OpenLDAP 2.4.11 does not support BDB 4.7. Use OpenLDAP 2.4.12 or later for BDB 4.7 support. And make sure you have all 3 patches for BDB 4.7. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5899) make fails on AIX5.3
by masterson.andrew＠gmail.com 21 Jan '09

21 Jan '09

Full_Name: Andrew Version: 2.4.11 OS: AIX5.3 64 bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.98.237.232) configure runs CPPFLAGS=-I/usr/local/BerkeleyDB.4.7/include LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib ./configure --enable-ipv6 (and gives warnings about openssl and Cyrus SASL not being installed - otherwise fine) make fails with the following error: cd back-bdb; make all rm -f version.c ../../../build/mkversion -v "2.4.11" back_bdb > version.c /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc_r -g -I../../../include -I../../../include -I.. -I./.. -I/usr/local/BerkeleyDB.4.7/include -c init.c cc_r -g -I../../../include -I../../../include -I.. -I./.. -I/usr/local/BerkeleyDB.4.7/include -c init.c -o init.o "init.c", line 509.49: 1506-022 (S) "lk_handle" is not a member of "struct __db_env". "init.c", line 752.32: 1506-280 (W) Function argument assignment between types "int(*)(unsigned long,unsigned long)" and "int(*)(void)" is not allowed. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop.

1 0

Re: (ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by michael＠stroeder.com 21 Jan '09

21 Jan '09

quanah(a)zimbra.com wrote: > --On Saturday, January 17, 2009 3:25 PM +0000 michael(a)stroeder.com wrote: > >> Howard Chu wrote: >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: HEAD >>>> OS: Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (84.163.100.169) >>>> >>>> >>>> lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion >>>> `!(*(&((lc))->lc_lcflags) >>>> & (((0x00000020U))))' failed. >>> I'm not seeing that here. Ran into a couple other problems though, fixed >>> now in HEAD. Please re-test... >> Now test008 hangs... > > Multiple runs of test008 work for me, using BDB 4.7.25 with all 3 patches, > and HEAD CVS as of 1/20/2009 @ 12:00 PST. > > Did you fully rebuild OpenLDAP after the latest commits? What version of > BDB are you using? Is it fully patched? What backend was it using when it > hung? Did you get a backtrace of where it hung? I'm using libdb-4_5-4.5.20-94.17 from openSUSE 11.1 which is AFAIK fully patched. The interesting fact is that HEAD currently hangs all the time in test008. RE24 with your recent changes now fails as described in test039. Before these changes RE24 just worked fine. I think this is related to modifications in connection.c because trouble started after HEAD contained these changes. Ciao, Michael.

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ando＠sys-net.it 21 Jan '09

21 Jan '09

ghenry(a)suretecsystems.com wrote: > ----- ando(a)sys-net.it wrote: > >> Gavin Henry wrote: >>> Sorry, I presume this was a bug in the code and the docs document >> the >>> right behaviour? >>> >>> I'll revert them when you've confirmed. >> As far as I remember, the bug was in the example in >> slapo-constraint(5) >> man page ("[:digit:]" indicates the collection of values ":", "d", >> "i", >> ..., while "[[:digit:]]" indicates "0"->"9"). The man page is correct >> > > OK, it was actually this bit: > > constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ > > and in HEAD it still only had one set of []. Both the admin guide and man page > have been updated for this in my last commit. Definitely my fault: apparently, I fixed it in my working copy long ago (maybe while offline) and forgot to commit. I just found it out because of a conflict when updating with your fix. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ghenry＠suretecsystems.com 21 Jan '09

21 Jan '09

----- ando(a)sys-net.it wrote: > Gavin Henry wrote: > > Sorry, I presume this was a bug in the code and the docs document > the > > right behaviour? > > > > I'll revert them when you've confirmed. > > As far as I remember, the bug was in the example in > slapo-constraint(5) > man page ("[:digit:]" indicates the collection of values ":", "d", > "i", > ..., while "[[:digit:]]" indicates "0"->"9"). The man page is correct > OK, it was actually this bit: constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ and in HEAD it still only had one set of []. Both the admin guide and man page have been updated for this in my last commit. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5889) [PATCH] Sending dereference field when retrying connection in meta backend
by ando＠sys-net.it 21 Jan '09

21 Jan '09

jorge.perez(a)adaptia.net wrote: > When we have two slapds with a established meta connection between them and the > connection is reset, for example by a router, the next search query will always > be send with never in dereferencing. > > Steps to reproduce: > > - Established a meta connection between 2 slapds > - Reset the connection, for example with cutter > - Send a search dereferencing with something different to never. > - See the results are no dereferenced. > > Patch attached. Thanks, fixed (with minor modifications). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5897) trailing characters in olcserverids after conversion
by oliver＠itc.li 21 Jan '09

21 Jan '09

Howard Chu schrieb: > oliver(a)itc.li wrote: >> Full_Name: Oliver Liebel >> Version: 2.4.13 >> OS: opensuse 11 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.144.97.81) >> >> >> using openldap 2.4.13 (compiled from openldap.org source-package) >> i have noticed the following, reproducable behaviour when converting >> a slapd.conf to slapd.d: >> >> if slapd.conf contains serverids with ldap-urls, e.g. in this format: >> >> ServerID 1 "ldap://ldapmaster.local.site:9000" >> ServerID 2 "ldap://ldapslave.local.site:9000" >> >> the olcserverids in cn=config.ldif always contains some trailing >> (garbage) >> characters after the conversion, and are base64 encoded. when i set >> them >> manually in cn=config with ldapmodify, they are displayed "clean". >> >> the serverid-lines in slapd.conf are "clean" (they contain no >> whitespaces / tabs >> at the end of the line or similar, invisible characters). >> >> i have tested it several times, without using \"\ in the string >> and/or without >> portnumber. i have tested the conversion with both slaptest and slapd, >> in virtual and real machines, >> result was always the same. > > Thanks for the report, this is now fixed in HEAD. Note, URLs don't > need to be surrounded with quotes. By definition, they are already > "safe". okay, understood. thanks for your response. greetings oliver

1 0

Re: (ITS#5898) test044 abort with back-ldif
by h.b.furuseth＠usit.uio.no 21 Jan '09

21 Jan '09

> When using the back-ldif backend with test044, it aborts: Probably ITS#5340. -- Hallvard

1 0

(ITS#5898) test044 abort with back-ldif
by quanah＠OpenLDAP.org 20 Jan '09

20 Jan '09

Full_Name: Quanah Gibson-Mount Version: HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) When using the back-ldif backend with test044, it aborts: Program terminated with signal 6, Aborted. (gdb) bt #0 0x000000395e030155 in raise () from /lib64/libc.so.6 #1 0x000000395e031bf0 in abort () from /lib64/libc.so.6 #2 0x000000395e0295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000438a3b in entry2str (e=0x1e88, len=0x438a49) at entry.c:452 #4 0x0000000004fe9748 in ?? () #5 0x0000000000000000 in ?? () (gdb) frame 3 #3 0x0000000000438a3b in entry2str (e=0x1e88, len=0x438a49) at entry.c:452 452 tmplen = e->e_name.bv_len; (gdb) l 447 ecur = ebuf; 448 449 /* put the dn */ 450 if ( e->e_dn != NULL ) { 451 /* put "dn: <dn>" */ 452 tmplen = e->e_name.bv_len; 453 MAKE_SPACE( LDIF_SIZE_NEEDED( 2, tmplen )); 454 ldif_sput( &ecur, LDIF_PUT_VALUE, "dn", e->e_dn, tmplen ); 455 } 456

1 0

Re: (ITS#5896) search error on ldap_search_ext_s
by hyc＠symas.com 20 Jan '09

20 Jan '09

eduard.budulea(a)axigen.com wrote: > Full_Name: Eduard Budulea > Version: 2.4.11 > OS: gnu/linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.230.245.6) > > > ldap_search_ext_s does not return all the messages that the server sends. > If the response from the ldap server is compose from 2 messages: > - a LDAP Intermediate Response Message > - a SearchResultDone Message > > the ldap_search_ext_s returns only the intermediate one. > > Step to reporduce: > have a ldap running with some entries. > have a the syncprov overlay deploy. > make a synchronous search with a null cookie and a filter that does not match > all the entries. > now modify an entry that is not in the previous result set. > make another synchronous search with the cookie from the previous search. > you will be able to see only the intermediate and not the done (that holds the > cookie). > > If you do the same but using ldap_search_ext and ldap_result you will get the > result done message also. This behavior is by design, and has been in place since 2000. Whether the design is correct or not may be an open question; since Kurt wrote that code I'd ask him to comment further. -- -- 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#5897) trailing characters in olcserverids after conversion
by hyc＠symas.com 20 Jan '09

20 Jan '09

oliver(a)itc.li wrote: > Full_Name: Oliver Liebel > Version: 2.4.13 > OS: opensuse 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.144.97.81) > > > using openldap 2.4.13 (compiled from openldap.org source-package) > i have noticed the following, reproducable behaviour when converting > a slapd.conf to slapd.d: > > if slapd.conf contains serverids with ldap-urls, e.g. in this format: > > ServerID 1 "ldap://ldapmaster.local.site:9000" > ServerID 2 "ldap://ldapslave.local.site:9000" > > the olcserverids in cn=config.ldif always contains some trailing (garbage) > characters after the conversion, and are base64 encoded. when i set them > manually in cn=config with ldapmodify, they are displayed "clean". > > the serverid-lines in slapd.conf are "clean" (they contain no whitespaces / tabs > at the end of the line or similar, invisible characters). > > i have tested it several times, without using \"\ in the string and/or without > portnumber. i have tested the conversion with both slaptest and slapd, > in virtual and real machines, > result was always the same. Thanks for the report, this is now fixed in HEAD. Note, URLs don't need to be surrounded with quotes. By definition, they are already "safe". -- -- 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#5897) trailing characters in olcserverids after conversion
by quanah＠zimbra.com 20 Jan '09

20 Jan '09

--On Monday, January 19, 2009 5:41 PM +0000 oliver(a)itc.li wrote: > Full_Name: Oliver Liebel > Version: 2.4.13 > OS: opensuse 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.144.97.81) > > > using openldap 2.4.13 (compiled from openldap.org source-package) > i have noticed the following, reproducable behaviour when converting > a slapd.conf to slapd.d: > i have tested it several times, without using \"\ in the string and/or > without portnumber. i have tested the conversion with both slaptest and > slapd, in virtual and real machines, > result was always the same. Can you test with current CVS of HEAD? back-ldif has been largely reworked. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ando＠sys-net.it 20 Jan '09

20 Jan '09

Gavin Henry wrote: > Sorry, I presume this was a bug in the code and the docs document the > right behaviour? > > I'll revert them when you've confirmed. As far as I remember, the bug was in the example in slapo-constraint(5) man page ("[:digit:]" indicates the collection of values ":", "d", "i", ..., while "[[:digit:]]" indicates "0"->"9"). The man page is correct in HEAD, but the correction is not in re24. The code has always been correct with respect to this issue both in HEAD and re24. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by quanah＠zimbra.com 20 Jan '09

20 Jan '09

--On Saturday, January 17, 2009 3:25 PM +0000 michael(a)stroeder.com wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Str?der >>> Version: HEAD >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (84.163.100.169) >>> >>> >>> lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion >>> `!(*(&((lc))->lc_lcflags) >>> & (((0x00000020U))))' failed. >> >> I'm not seeing that here. Ran into a couple other problems though, fixed >> now in HEAD. Please re-test... > > Now test008 hangs... Multiple runs of test008 work for me, using BDB 4.7.25 with all 3 patches, and HEAD CVS as of 1/20/2009 @ 12:00 PST. Did you fully rebuild OpenLDAP after the latest commits? What version of BDB are you using? Is it fully patched? What backend was it using when it hung? Did you get a backtrace of where it hung? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#5789 using IP address in CN with GnuTLS
by hyc＠symas.com 20 Jan '09

20 Jan '09

Upon further re-reading of RFC4513 and RFC2818, I think the original behavior was correct. An IP address is only allowed to match an IP Address subjectAltName, it is not allowed to match the certificate CN. -- -- 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#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 20 Jan '09

20 Jan '09

Pierangelo, Executing some test I'm not sure anymore if this is really a memory leakage or if some cache issue. I decided to install CentOS5.2 where I could have OpenLdap 2.3.27 compiled by the distribution and then execute more tests to check if some library in RHEL4 would be causing some problem. I then use a similar slapd.conf as in my original e-mail just without explicitly define an size for cache and idlcache there. My DB_CONFIG file has a cache defined as 50MB what is respected. Looking at some other ITS I found the ITS#3938 what I believe is very similar to my problem. I still have a DB with 3882998 entrances and where the DB files at disk is around 15GB. My machine has 12GB of memory where for sure all the DB cannot be cached into memory. In any case what is happening is that every time a transaction is done with OpenLdap, even a distribution formal compilation, the cache continues to grow until consumes all memory. If the DB is bigger than machine memory then soon or later a memory out of range will happen. The cache is never release by OpenLdap and then if a sequential search is done and since DB is bigger than memory we can speed up the problem. I also used Valgrind where I obtained : ==4963== LEAK SUMMARY: ==4963== definitely lost: 0 bytes in 0 blocks. ==4963== possibly lost: 0 bytes in 0 blocks. ==4963== still reachable: 336,091 bytes in 12,547 blocks. ==4963== suppressed: 0 bytes in 0 blocks. ==4963== Reachable blocks (those to which a pointer was found) are not shown. ==4963== To see them, rerun with: --show-reachable=yes [root@brtldp12 bdbBackupContent]# ==4964== Conditional jump or move depends on uninitialised value(s) ... Valgrind's memory management: out of memory: newSuperblock's request for 1048576 bytes failed. 2952183808 bytes have already been allocated. Valgrind cannot continue. Sorry. See it consume all the available memory and then could not allocate more memory. I also have an old version of OpenLdap in other machine with the same HW where the same DB has even more entrances. I'm trying to upgrade the OpenLdap to improve other itens but this appears to not be possible. At this old version I do not have this infinite cache problem and the only memory consumed is the Berkeley DB cache defined as 50MB. I could ldapsearch all the DB but once cache is allocated it never release it. At top I can see the memory continues associated with slapd process even the ldapsearch ends. Then if we start other ldapsearch then memory continues to be allocated. For information the old version informations is : openldap 2.1.30 and BerkeleyDB 4.2.52 With this version above I have a DB bigger than the available memory and I do not have this cache problem. I also do not have entrances like idelcache or anything else at slapd.conf file. At this way at new versions if for some reason you have a file DB bigger than your available memory with time you will have problems with OpenLdap. I will try again to force the idlcache and openldap cache but the last time tried this did not work. In this way I would identify better this problem and ask if you see this is as a bug or if some configuration would "force" openldap to cache(clean it) only using certain maximum size? Regards, Rodrigo. --- On Tue, 12/30/08, Pierangelo Masarati <ando(a)sys-net.it> wrote: > From: Pierangelo Masarati <ando(a)sys-net.it> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)openldap.org > Date: Tuesday, December 30, 2008, 2:06 PM > rlvcosta(a)yahoo.com wrote: > > --0-1358063323-1230648878=:64021 > > Content-Type: text/plain; charset=iso-8859-1 > > Content-Transfer-Encoding: quoted-printable > > > > Pierangelo, > > > > I could run the valgrind but at this time I do not > have the DB with the aro= > > und 4 million subscribers. In this condition, with a > small number of users,= > > I already could see some "definitive" > memory leaks and I believe they are = > > associated with OpenLdap. > > > > Just for a history I already compiled the openldap > 2.4.11 souce code withou= > > t modules and TLS since many lists make reference to > some possible issues i= > > n RHEL with TLS. Even so I could not have a load > without the possible memor= > > y leak. > > > > So I do not believe the problems are in the RHEL > libtool or glibc. > > > > In any case the result for the valgrind is (short > number of entrances at th= > > is time): > > You probably need to use an unstripped binary in order to > find out where mallocs/frees occur. Most of the occurrences > you notice are either one-time leaks. Moreover, 2.4.13 is > out, and it might have fixed some. I suggest you further > investigate using the latest code, using an unstripped > binary. > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > -----------------------------------

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by gavin.henry＠gmail.com 19 Jan '09

19 Jan '09

Sorry, I presume this was a bug in the code and the docs document the right behaviour? I'll revert them when you've confirmed. On 19/01/2009, ando(a)sys-net.it <ando(a)sys-net.it> wrote: > marjan.blatnik(a)gov.si wrote: >> Full_Name: Marjan Blatnik >> Version: 2.4.13 >> OS: Debian GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.2.236.13) >> >> >> Example in slapo-constraint manual is not precise. >> The line >> constraint_attribute mail regex ^[:alnum:]+@mydomain.com$ >> should be >> constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ >> >> And similar in >> http://www.openldap.org/doc/admin24/overlays.html#Constraints > > This is already fixed in HEAD, but apparently has not been ported to > 2.4. Thanks for noticing it. > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ghenry＠OpenLDAP.org 19 Jan '09

19 Jan '09

----- "marjan blatnik" <marjan.blatnik(a)gov.si> wrote: > Full_Name: Marjan Blatnik > Version: 2.4.13 > OS: Debian GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.2.236.13) > > > Example in slapo-constraint manual is not precise. > The line > constraint_attribute mail regex ^[:alnum:]+@mydomain.com$ > should be > constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ > > And similar in > http://www.openldap.org/doc/admin24/overlays.html#Constraints Thanks, updated. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5897) trailing characters in olcserverids after conversion
by oliver＠itc.li 19 Jan '09

19 Jan '09

Full_Name: Oliver Liebel Version: 2.4.13 OS: opensuse 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.144.97.81) using openldap 2.4.13 (compiled from openldap.org source-package) i have noticed the following, reproducable behaviour when converting a slapd.conf to slapd.d: if slapd.conf contains serverids with ldap-urls, e.g. in this format: ServerID 1 "ldap://ldapmaster.local.site:9000" ServerID 2 "ldap://ldapslave.local.site:9000" the olcserverids in cn=config.ldif always contains some trailing (garbage) characters after the conversion, and are base64 encoded. when i set them manually in cn=config with ldapmodify, they are displayed "clean". the serverid-lines in slapd.conf are "clean" (they contain no whitespaces / tabs at the end of the line or similar, invisible characters). i have tested it several times, without using \"\ in the string and/or without portnumber. i have tested the conversion with both slaptest and slapd, in virtual and real machines, result was always the same. greetings, oliver

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs