openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

(ITS#5417) ldap memory utilization extremely high
by james＠broadsoft.com 12 Mar '08

12 Mar '08

Full_Name: J B Version: openldap-2.3.27 OS: FreeBSD 4.7-RELEASE-p28 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.88.7.2) The ldap process periodically shows high CPU utilization. It will gradually climb from an extremely low number to up to 95%, then gradually return to an extremely low number again. The server is running ldap to authenticate for a Plone/zope for which the user needs to log in. In this instance the process is extremely low. However at times it can reach 85%. During these times, the login process can take up to 30 seconds. It seems when the utilization is low, the login process is only 1 second. PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 34154 zope2 2 0 1173M 1165M poll 1 21.2H 14.06% 14.06% python2 370 ldap 2 0 149M 12564K poll 0 469.1H 2.34% 2.34% slapd another top output shows that slpad actually reached 0% PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 62976 root 28 0 2068K 1064K CPU1 1 0:01 16.10% 3.56% top4 370 ldap 2 0 149M 12564K poll 0 469.1H 0.00% 0.00% slapd

1 0

Re: (ITS#5414) About nis.schema
by h.b.furuseth＠usit.uio.no 12 Mar '08

12 Mar '08

I wrote: > Rename your hacked nis.schema and put it somewhere an upgrade will not > touch. ..and include that instead of nis.schema from slapd.conf, if that wasn't clear. -- Hallvard

1 0

Re: (ITS#5414) About nis.schema
by h.b.furuseth＠usit.uio.no 12 Mar '08

12 Mar '08

jtwang(a)cs.nctu.edu.tw writes: > When we upgrade the openldap server, the modifed "nis.schema" would be > replaced with a unmodified "nis.schema". > > Our servers will be down, because there are some strings in database which > conflicts to "nis.schema". Rename your hacked nis.schema and put it somewhere an upgrade will not touch. > May you change the default schema of the "gecos" field and make it to > be able to carry dual-byte string? Unfortunately, no. The schema is defined in RFC2307, which specifies IA5 String (ASCII) gecos. OpenLDAP follows that, and a change would cause interoperability problems with servers which still follow the RFC. You could write the RFC author and ask if there are plans to update to use Directory String. So, not an OpenLDAP bug. This ITS will be closed. -- Hallvard

1 0

(ITS#5416) slapd core dump
by rui.yan＠gmail.com 12 Mar '08

12 Mar '08

Full_Name: yanr Version: 2.4.8 OS: Linux 2.6.22 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.221.197.21) Verion: 2.4.8 Desc: client runs some codes like ldap_modify_ext, sometimes slapd core dump. The same codes works on 2.3.38. [root@test1 /]# uname -r 2.6.22.9-2.smp.gcc3.4.x86_64 (gdb) bt #0 0x00002b018fa6da3d in *__GI_raise (sig=19040) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 67 int res = INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x00002b018fa6da3d in *__GI_raise (sig=19040) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 #1 0x00002b018fa6ef1e in *__GI_abort () at ../sysdeps/generic/abort.c:88 #2 0x00002b018fa67720 in *__GI___assert_fail (assertion=0x56ad43 "i > 0", file=0x56acf8 "schema_init.c", line=366, function=0x56ad30 "octetStringIndexer") at assert.c:83 #3 0x00000000004664b3 in octetStringIndexer (use=163, flags=4, syntax=0x77ea70, mr=0x77ed70, prefix=0x77ec48, values=0x2aaaaacad6b0, keysp=0x42001598, ctx=0x83d970) at schema_init.c:366 #4 0x000000000046ffde in objectSubClassIndexer (use=163, mask=4, syntax=0x77ea70, mr=0x77ed70, prefix=0x77ec48, values=0x87b7e0, keysp=0x42001598, ctx=0x83d970) at schema_prep.c:305 #5 0x00000000004e898b in indexer (op=0x839cc0, txn=0x87c680, ad=0x7789b0, atname=0x77ec48, vals=0x87b7e0, id=86, opid=2, mask=4) at index.c:205 #6 0x00000000004e8e2d in index_at_values (op=0x839cc0, txn=0x87c680, ad=0x7789b0, type=0x77ebe0, tags=0x7789d0, vals=0x87b7e0, id=86, opid=2) at index.c:337 #7 0x00000000004e8fa6 in bdb_index_values (op=0x839cc0, txn=0x87c680, desc=0x7789b0, vals=0x87b7e0, id=86, opid=2) at index.c:386 #8 0x00000000004ae4d6 in bdb_modify_internal (op=0x839cc0, tid=0x87c680, modlist=0x87b700, e=0x420018f0, text=0x42002e30, textbuf=0x42001980 "��\213\216\001+", textlen=256) at modify.c:287 #9 0x00000000004af29c in bdb_modify (op=0x839cc0, rs=0x42002e10) at modify.c:577 #10 0x0000000000443710 in fe_op_modify (op=0x839cc0, rs=0x42002e10) at modify.c:300 #11 0x0000000000443172 in do_modify (op=0x839cc0, rs=0x42002e10) at modify.c:175 #12 0x000000000042629d in connection_operation (ctx=0x42002f60, arg_v=0x839cc0) at connection.c:1084 #13 0x00000000004267d9 in connection_read_thread (ctx=0x42002f60, argv=0xc) at connection.c:1211 #14 0x000000000052409d in ldap_int_thread_pool_wrapper (xpool=0x78ab30) at tpool.c:625 #15 0x00002b018e8bc35a in start_thread () from /lib64/tls/libpthread.so.0 #16 0x00002b018faf6473 in clone () from /lib64/tls/libc.so.6 #17 0x0000000000000000 in ?? ()

1 0

(ITS#5414) About nis.schema
by jtwang＠cs.nctu.edu.tw 11 Mar '08

11 Mar '08

Full_Name: Jiun-Tsung Wang Version: 2.3.41 OS: FreeBSD 6.3-Release URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (140.113.166.53) Hello, We can't store any dual-byte(including UTF-8) string in "gecos" field which be declared in "nis.schema". But we need to store some Chinese information in it. We store Chinese information by modifying the nis.schema from attributetype ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) to attributetype ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) . When we upgrade the openldap server, the modifed "nis.schema" would be replaced with a unmodified "nis.schema". Our servers will be down, because there are some strings in database which conflicts to "nis.schema". May you change the default schema of the "gecos" field and make it to be able to carry dual-byte string? Thanks! -- Jiun-Tsung Wang(jtwang(a)cs.nctu.edu.tw) Computer Center of Computer Science Department, Nation Chiao-Tung University, Taiwan R.O.C

1 0

(ITS#5413) typo in syncrepl.c causes SEGV
by hyc＠OpenLDAP.org 11 Mar '08

11 Mar '08

Full_Name: Howard Chu Version: 2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc in compare_csns, sc1->ctxcsns[i] is compared against sc2->ctxcsns[i], the latter should have been [j] instead.

1 0

Re: (ITS#5409) paged results invalid sizelimit error
by quanah＠zimbra.com 11 Mar '08

11 Mar '08

--On Tuesday, March 11, 2008 4:14 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.41 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (24.23.156.219) >> >> >> Intermittently if the max entries requested is exact multiple of page >> size, after a paged search hits SizeLimitExceededException, the next >> search also always throws a SizeLimitExceededException, even when it >> should not. > > Does "the next search" also use the paging control? Yes. >> e.g. if max requested is 5000, if page size is: >> 1000 => bad >> 2500 => bad >> 999 => good >> 2000 => good >> >> I have a java program that can reproduce this. > > Are you sure it's not AdminLimitExceeded? Yes. javax.naming.SizeLimitExceededException: [LDAP: error code 4 - Sizelimit Exceeded]; > Does the same situation occur in 2.4? I don't have 2.4 available to test with at this time. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5409) paged results invalid sizelimit error
by hyc＠symas.com 11 Mar '08

11 Mar '08

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.41 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > Intermittently if the max entries requested is exact multiple of page size, > after a paged search hits SizeLimitExceededException, the next search also > always throws a SizeLimitExceededException, even when it should not. Does "the next search" also use the paging control? > e.g. if max requested is 5000, if page size is: > 1000 => bad > 2500 => bad > 999 => good > 2000 => good > > I have a java program that can reproduce this. Are you sure it's not AdminLimitExceeded? Does the same situation occur in 2.4? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5412) Add operation should not require naming attrs
by h.b.furuseth＠usit.uio.no 11 Mar '08

11 Mar '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard A somewhat belated ITS: ldapadd of dn: o=foo objectClass: organization complains that "naming attribute 'o' is not present in entry". RFC 2251 required this, but RFC 4511 changed it to the opposite: The RDN attrs need not be present in AddRequest.attributes. slapd and slapadd should generate them if they are missing. I don't know if the change belongs in RE23.

1 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by h.b.furuseth＠usit.uio.no 11 Mar '08

11 Mar '08

jclarke(a)linagora.com writes: > > Eh. API design bug. (...) > Hmmm. I may have misunderstood, (...) No, I did. I'll file a separate ITS for it. -- Hallvard

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs