- openldap-bugs - openldap.org

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by Quanah Gibson-Mount 17 Apr '09

17 Apr '09

--On Friday, April 17, 2009 10:25 PM +0300 sscdvp(a)gmail.com wrote: > Why do you have so many threads configured? How many cpu's do you have?? > > > >> I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from >> Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > I have an application which generates heavy load in slapd (many > ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). > BDB databases are situated on separate disk and BDB logs are on the other > disk. But slapd performance (I mean time to answer) still cuts > down during large disk IO periods 'cause these disks are used by other > applications at the same time. And so I have increased number of threads > from the defaults threads=32 up to 64, just to save some time for my > application which requires not more then 30 ms for one search to > complete. > Just to be sure I have tried the default settings for threads and it's > behaviour didn't changed - slapd heap memory just continuously grows (I > have seen through pmap)... > Also I have tried libtcmalloc which is usually recommended and solaris > built in' libmtmalloc, but it didn't helped. Please copy replies to the bug tracker if you expect help. I will note that every thread consumes a large chunk of memory. I will also note that the default is 16 threads, not 32. I will also note, that as far as read operations are concerned, usually *fewer* threads is faster, not more. You appear to have quite an excessive amount of threads configured. Others will have to continue the conversation on what you're seeing growth wise. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 17 Apr '09

17 Apr '09

2009/4/17, sscdvp(a)gmail.com <sscdvp(a)gmail.com>: > > > > > > > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > > According to ITS#5860 slapd should not allocate more memory than it was > > > specified. In fact I have the same behaviour as it was with previous > > > > > > version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for > > > set_cachesize 300 MB). But slapd process continuosly grows in memory until > > > 32-bit limit then crashes due to unavalable memory resources. I need to > > > > > > mention bdb database size is less then 1 GB. > > > After restart it rapidly consumes 1.5 GB RSS in few minutes and then it > > > grows beyond the limit during 24 hours. The more queries are processing > > > the more memory it eats. > > > > > > I am using this database for logging which size grows. > > > The question is: is it possible to use 32-bit openldap with relatively > > > large database sizes that override 32-bit per-process memory space? > > > > > > My slapd.conf contains: > > > > > > > > > threads 64 > > > > > > > Why do you have so many threads configured? How many cpu's do you have?? > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > I have an application which generates heavy load in slapd (many ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). BDB databases are situated on separate disk and BDB logs are on the other disk. But slapd performance (I mean time to answer) still cuts down during large disk IO periods 'cause these disks are used by other applications at the same time. And so I have increased number of threads from the defaults threads=32 up to 64, just to save some time for my application which requires not more then 30 ms for one search to complete. > Just to be sure I have tried the default settings for threads and it's behaviour didn't changed - slapd heap memory just continuously grows (I have seen through pmap)... > Also I have tried libtcmalloc which is usually recommended and solaris built in' libmtmalloc, but it didn't helped.

1 0

Re: (ITS#6058) slapcat aborts on a double free
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

luca(a)openldap.org writes: > Slapcat on a slapd instance using rwm overlay, aborts with: > *** glibc detected *** free(): invalid pointer: 0x09ed06e3 *** It's an invalid free() of (static EntryHeader eh).e_bv.bv_val at: ch_free (ch_malloc.c:139) hdb_tool_entry_close (back-hdb/tools.c:164) slapcat (slapcat.c:135) main (main.c:636) already freed (as (Entry *e)->e_bv.bv_val) at: ch_free (ch_malloc.c:139) entry_clean (entry.c:498) entry_free (entry.c:514) rwm_entry_release_rw (overlays/rwm.c:827) overlay_entry_release_ov (backover.c:421) over_entry_release_rw (backover.c:463) be_entry_release_rw (backend.c:867) slapcat (slapcat.c:117) main (main.c:636) I needed to prepend include servers/slapd/schema/core.schema to your config. -- Hallvard

1 0

Re: (ITS#5975) minor issue with slapd.conf manpage
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

eric(a)huss.org wrote: > There appears to be a couple slightly incorrect statements in the slapd.conf > manpage. It says that the argsfile and pidfile values are used "if started > without the debugging command line option". However, it doesn't appear to > make any difference whether or not you use the -d option with slapd. Fixed the doc in HEAD. Also the argsfile did not mention that the program name is written to argsfile as well as the options. -- Hallvard

1 0

Re: (ITS#6059) Abandon syncprov race condition?
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

rein(a)OpenLDAP.org writes: > I've had two cases where a delete operation was performed on the > master without being replicated to its consumers, which so far appear > to be cases of possible connection lost (abandon) race conditions. Not sure if this is the problem, but it is ugly: slapd/cancel.c sets o_abandon with op->o_conn->c_mutex locked, but waits to set o_cancel after it's unlocked. Looks like that can give slapd a chance to react to o_abandon before it "knows" that abandon is actually a cancel. > Do we need some sort of o_committed flag that can be used to prevent > o_abandon from being set or acted upon? Or handle o_abandon more like > o_cancel, i.e with multiple values, including "too late"? o_cancel is a wrapper around o_abandon, turning result code SLAPD_ABANDON into LDAP_TOO_LATE etc. However slap_send_ldap_result() and send_ldap_response() skip "if (op->o_callback) slap_response_play()" if o_abandon is set, and "send" SLAPD_ABANDON instead of the result code. Can that work right? The code looks like SLAPD_ABANDON ought to mean "nothing was done" right up till everything has had a chance to react the same way to an operation. -- Hallvard

1 0

Re: (ITS#6065) slapcat with sql (postgres) backend
by ando＠sys-net.it 17 Apr '09

17 Apr '09

frederic.bouy(a)gmail.com wrote: > Full_Name: Frederic Bouy > Version: 2.4.12 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.255.106.203) > > > When running the following command: > slapcat -l /tmp/lnp.ldif -f /usr/local/openldap/etc/openldap/slapd.conf -d 1 > I get this error message: > <==backsql_load_schema_map() > ==>backsql_free_db_conn() > ==>backsql_close_db_handle(0x8290c18) > <==backsql_close_db_handle(0x8290c18) > <==backsql_free_db_conn() > <==backsql_db_open(): test succeeded, schema map loaded > slapcat: database doesn't support necessary operations. > > ldapsearch is successfull. > > Do you have any clue on how to solve this issue? The message should be pretty self explanatory. A solution consists in implementing the missing support. 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

(ITS#6065) slapcat with sql (postgres) backend
by frederic.bouy＠gmail.com 17 Apr '09

17 Apr '09

Full_Name: Frederic Bouy Version: 2.4.12 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.255.106.203) When running the following command: slapcat -l /tmp/lnp.ldif -f /usr/local/openldap/etc/openldap/slapd.conf -d 1 I get this error message: <==backsql_load_schema_map() ==>backsql_free_db_conn() ==>backsql_close_db_handle(0x8290c18) <==backsql_close_db_handle(0x8290c18) <==backsql_free_db_conn() <==backsql_db_open(): test succeeded, schema map loaded slapcat: database doesn't support necessary operations. ldapsearch is successfull. Do you have any clue on how to solve this issue? Thanks for your help.

1 0

Antwort: Re: (ITS#5837) slapd pthread_kill Core Dump AIX
by howard.allison＠pva.sozvers.at 17 Apr '09

17 Apr '09

--0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: multipart/alternative; Boundary="1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841" --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable This is a full Backtrace - about 200 MB of Real Memory available(from 2= GB), and 2 GB of swap available. Thanks #0 0xd04a7560 in pthread_kill () from /usr/lib/libpthread.a(shr_xpg5.o= ) No symbol table info available. #1 0xd04a69cc in _p_raise () from /usr/lib/libpthread.a(shr_xpg5.o) No symbol table info available. #2 0xd01367e4 in raise () from /usr/lib/libs.a(shr.o) No symbol table info available. #3 0xd01a9028 in abort () from /usr/lib/libs.a(shr.o) No symbol table info available. #4 0xd0164878 in __assert_c99 () from /usr/lib/libs.a(shr.o) No symbol table info available. #5 0x1000cbe4 in ch_malloc (size=3D8388608) at ch_malloc.c:57 new =3D (void *) 0x0 #6 0x1022a80c in search_stack (op=3D0x243de2d8) at search.c:1013 bdb =3D (struct bdb_info *) 0x20188b98 ret =3D (void *) 0x0 #7 0x1022ac0c in search_candidates (op=3D0x243de2d8, rs=3D0x263ba824, e=3D0x263b9bc4, locker=3D0x51eadec0, ids=3D0x262f9bc4, scopes=3D0x26379= bc4) at search.c:1099 bdb =3D (struct bdb_info *) 0x20188b98 rc =3D 640653952 depth =3D 3 f =3D {f_choice =3D 160, f_un =3D {f_un_result =3D 640653996, f= _un_desc =3D 0x262f9aac, f_un_ava =3D 0x262f9aac, f_un_ssa =3D 0x262f9aac, f_un_mra =3D 0x262f9aac, f_un_complex =3D 0x262f9aac}, f_next =3D 0= x0} rf =3D {f_choice =3D 163, f_un =3D {f_un_result =3D 640654008, = f_un_desc =3D 0x262f9ab8, f_un_ava =3D 0x262f9ab8, f_un_ssa =3D 0x262f9ab8, f_un_mra =3D 0x262f9ab8, f_un_complex =3D 0x262f9ab8}, f_next =3D 0= x286ef7dc} xf =3D {f_choice =3D 161, f_un =3D {f_un_result =3D 640653972, = f_un_desc =3D 0x262f9a94, f_un_ava =3D 0x262f9a94, f_un_ssa =3D 0x262f9a94, f_un_mra =3D 0x262f9a94, f_un_complex =3D 0x262f9a94}, f_next =3D 0= x0} nf =3D {f_choice =3D 0, f_un =3D {f_un_result =3D 0, f_un_desc = =3D 0x0, f_un_ava =3D 0x0, f_un_ssa =3D 0x0, f_un_mra =3D 0x0, f_un_complex =3D = 0x0}, f_next =3D 0x262f9aa0} stack =3D (ID *) 0x1020cc58 aa_ref =3D {aa_desc =3D 0x200c0268, aa_value =3D {bv_len =3D 8,= bv_val =3D 0x102dbf2c "r\ef\erral"}} sf =3D {f_choice =3D 0, f_un =3D {f_un_result =3D 641440756, f_= un_desc =3D 0x263b9bf4, f_un_ava =3D 0x263b9bf4, f_un_ssa =3D 0x263b9bf4, f_un_mra =3D 0x263b9bf4, f_un_complex =3D 0x263b9bf4}, f_next =3D 0= x262f9ad0} aa_subentry =3D {aa_desc =3D 0x0, aa_value =3D {bv_len =3D 0, b= v_val =3D 0x0}} bv_ref =3D {bv_len =3D 8, bv_val =3D 0x102dbf2c "r\ef\erral"} #8 0x10228ee4 in bdb_search (op=3D0x243de2d8, rs=3D0x263ba824) at sear= ch.c:578 bdb =3D (struct bdb_info *) 0x20188b98 id =3D 0 cursor =3D 0 lastid =3D 4294967295 candidates =3D {0 <repeats 131072 times>} scopes =3D {0 <repeats 63759 times>, 641435536, 0, 0, 0, 0, 4030840384, 0 <repeats 11 times>, 641435684, 0 <repeats 206 times>, 641434560, 0 <repeats 11 times>, 641434656, 0, 0, 0, 641434656, 4030840384, 3490904144, 0, 0, 4030840384, 0, 0, 0, 0, 0, 0, 641434672, 0, 0, 0, 32,= 58, 22528, 0, 0, 11, 58, 4030431112, 641434720, 2567258180, 3490905504, 0= , 641434768, 4030840384, 4112, 0, 4030805596, 4030426872, 608034984, 959840256, 110, 608035812, 0, 0, 641434800, 0, 3490902496, 0, 6414348= 00, 4030840384, 58, 22528, 0, 144, 0, 269721729, 269721729, 4030854004, 3490917464, 0, 641434880, 4112, 58, 4030431112, 641434880, 4030840384= , 3490883944, 0, 641434896, 4030840384, 3490889600, 641435752, 641434896,= 4030840384, 3491274292, 0, 0, 641437345, 641437340, 1, 0, 1, 40304311= 12, 4030431112, 641434960, 0, 3490885628, 641435752, 641435008, 4030840384,= 3491268044, 0, 641434976, 4030840384, 0, 0, 641434992, 0, 0, 641435752= , 641435008, 4031927728, 3491274292, 608035800, 641435072, 297, 3490878276, 0, 641435072, 4030840384, 3490889836, 0, 641435072, 4030840384, 3490889600, 641435752, 641435648, 4030840384, 3491266240, 0= , 0, 4030840384, 0, 14, 32, 608035800, 0, 0, 0, 0, 14, 14, 641435168, 0, 3490878896, 0, 0, 4030840384, 0 <repeats 11 times>, 608035800, 1, 0, 641437088...} e =3D (Entry *) 0x0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 678360812, bv_val = =3D 0x23a301e0 ""}, e_nname =3D {bv_len =3D 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"}, e_attrs =3D= 0x3, e_ocflags =3D 641440736, e_bv =3D {bv_len =3D 641440832, bv_val =3D 0xf= 041be40 ""}, e_private =3D 0x203a0f78} e_root =3D (Entry *) 0x2035880c matched =3D (Entry *) 0x0 ei =3D (EntryInfo *) 0x203a0f78 attrs =3D (AttributeName *) 0x0 realbase =3D {bv_len =3D 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc= =3Dsozv \ers,dc=3Dat"} mask =3D 5119 stoptime =3D 1239955337 manageDSAit =3D 0 tentries =3D 0 nentries =3D 0 idflag =3D 0 locker =3D 0x51eadec0 lock =3D {off =3D 0, ndx =3D 412, gen =3D 77770, mode =3D DB_LO= CK_READ} opinfo =3D (struct bdb_op_info *) 0x0 ltid =3D (DB_TXN *) 0x0 oex =3D (OpExtra *) 0x0 stub =3D {bv_len =3D 4030851424, bv_val =3D 0x0} #9 0x100d66dc in overlay_op_walk (op=3D0x243de2d8, rs=3D0x263ba824, which=3Dop_search, oi=3D0x20189d68, on=3D0x0) at backover.c:646 func =3D (BI_op_bind **) 0x200012b4 rc =3D 32768 sc_next =3D (slap_callback *) 0x0 #10 0x100d691c in over_op_func (op=3D0x243de2d8, rs=3D0x263ba824, which=3Dop_search) at backover.c:698 oi =3D (slap_overinfo *) 0x20189d68 on =3D (slap_overinst *) 0x20189e78 be =3D (BackendDB *) 0x20187f68 db =3D {bd_info =3D 0x20001288, bd_self =3D 0x20187f68, be_ctrls =3D "\000\001\001\001\000\001\000\000\001\000\000\001\001\00= 0 \001", '\0' <repeats 17 times>, "\001", be_flags =3D 2312, be_restricto= ps =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0= , sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}= , be_suffix =3D 0x20183b08, be_nsuffix =3D 0x20189a28, be_schemadn =3D {b= v_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, b= e_rootdn =3D {bv_len =3D 34, bv_val =3D 0x20189ce8 "cn=3DManag\er,dc=3Dpva,dc=3Dsozv\ers,dc=3Dat= "}, be_rootndn =3D {bv_len =3D 34, bv_val =3D 0x20189d38 "cn=3Dmanag\er,dc=3Dpva,dc=3Dsozv\ers,dc=3Dat= "}, be_rootpw =3D {bv_len =3D 5, bv_val =3D 0x20187138 "start"}, be_max_deref_depth =3D= 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D 0, lms_s_soft =3D= -1, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D 0, lms_s_pr_hide= =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D 0x2016b768, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D 0, bv_val =3D= 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x20356508, be_pcl_mu= tex =3D {__mt_word =3D {0, 0, 0, 1, 0, 1373, 0, 5, 0, 0, 0, 0, 0}}, be_pcl_mutexp =3D 0x20188034, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_= cf_ocs =3D 0x2001b2a8, be_private =3D 0x20188b98, be_next =3D {stqe_next =3D 0x201= 92308}} cb =3D {sc_next =3D 0x0, sc_response =3D @0x2001e51c: 0x100d553= c <over_back_response>, sc_cleanup =3D @0x0: 0x1, sc_private =3D 0x20189d= 68} rc =3D 32768 #11 0x100d6a84 in over_op_search (op=3D0x243de2d8, rs=3D0x263ba824) at backover.c:720 No locals. #12 0x100b3434 in fe_op_search (op=3D0x243de2d8, rs=3D0x263ba824) at search.c:366 bd =3D (BackendDB *) 0x20046498 entry =3D (Entry *) 0x1021638 #13 0x100b2b2c in do_search (op=3D0x243de2d8, rs=3D0x263ba824) at searc= h.c:217 base =3D {bv_len =3D 23, bv_val =3D 0x243e93ff "dc=3Dpva,dc=3Ds= ozv \ers,dc=3Dat"} siz =3D 0 off =3D 0 i =3D 0 dummy =3D 0x5469746c <Address 0x5469746c out of bounds> #14 0x1006c154 in connection_operation (ctx=3D0x263ba95c, arg_v=3D0x243= de2d8) at connection.c:1084 rc =3D 80 op =3D (Operation *) 0x243de2d8 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, sr_msgid =3D 0, s= r_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, = sr_un =3D { sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =3D 0= x0, r_rspdata =3D 0x0}, sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0= , r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r= _v2ref =3D 0x0}}, sr_flags =3D 0} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D (Connection *) 0x201bd448 memctx =3D (void *) 0x243de6b8 memctx_null =3D (void *) 0x0 memsiz =3D 1048576 curelm =3D (struct Operation *) 0x1 #15 0x1006c848 in connection_read_thread (ctx=3D0x263ba95c, argv=3D0x20= ) at connection.c:1211 rc =3D 0 cri =3D {op =3D 0x243de2d8, func =3D @0x0: 0x1, arg =3D 0x0, ct= x =3D 0x263ba95c, nullop =3D 0} s =3D 32 #16 0xd26daf88 in ldap_int_thread_pool_wrapper (xpool=3D0x200c9588) at tpool.c:663 pool =3D (struct ldap_int_thread_pool_s *) 0x200c9588 task =3D (ldap_int_thread_task_t *) 0x23e43ae8 work_list =3D (ldap_int_tpool_plist_t *) 0x200c961c ctx =3D {ltu_id =3D 1286, ltu_key =3D {{ltk_key =3D 0x2001e2ac,= ltk_data =3D 0x243de5a8, ltk_free =3D @0x2001e2b8: 0x1006b814 <conn_counter_destroy>= }, {ltk_key =3D 0x2001e048, ltk_data =3D 0x243de6b8, ltk_free =3D @0x2= 001e054: 0x1000a1e4 <slap_sl_mem_destroy>}, {ltk_key =3D 0x20020b20, ltk_data =3D 0x0, ltk_free =3D @0x20020b2c: 0x10009864 <slap_op_q_destroy>}, {ltk_key =3D 0x20356518, ltk_data =3D 0x51eadec0,= ltk_free =3D @0x200201fc: 0x1020f550 <bdb_locker_id_free>}, {ltk_= key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D @0x0: 0x1} <repeats 28 times>}} kctx =3D (ldap_int_thread_userctx_t *) 0x0 i =3D 32 keyslot =3D 171 hash =3D 171 ptr_ =3D (const unsigned char *) 0x263ba95c "" i_ =3D 4 #17 0xd048fc50 in _pthread_body () from /usr/lib/libpthread.a(shr_xpg5.= o) No symbol table info available. Mit freundlichen Gr=FC=DFen Howard ALLISON Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: howard.allison(a)pva.sozvers.at Internet: www.pensionsversicherung.at -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the individuality or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure. If you are not the intended recipient you are notified that any dissemination, distribution, use or copying of this communication is strictly prohibited. If you received this message in error, please immediately destroy this message. --------------------------= --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> This is a full Backtrace - about 200 MB of Real Mem= ory available(from 2 GB), and 2 GB of swap available. Thanks #0 0xd04a7560 in pthread_kill () from /usr/lib/libpth= read.a(shr_xpg5.o) No symbol table info available. #1 0xd04a69cc in _p_raise () from /usr/lib/libpthread= .a(shr_xpg5.o) No symbol table info available. #2 0xd01367e4 in raise () from /usr/lib/libs.a(shr.o)= No symbol table info available. #3 0xd01a9028 in abort () from /usr/lib/libs.a(shr.o)= No symbol table info available. #4 0xd0164878 in __assert_c99 () from /usr/lib/libs.a= (shr.o) No symbol table info available. #5 0x1000cbe4 in ch_malloc (size=3D8388608) at ch_mal= loc.c:57 new =3D (void *) 0x0 #6 0x1022a80c in search_stack (op=3D0x243de2d8) at se= arch.c:1013 bdb =3D (struct bdb_info *) 0x20188b98<= br> ret =3D (void *) 0x0 #7 0x1022ac0c in search_candidates (op=3D0x243de2d8, = rs=3D0x263ba824, e=3D0x263b9bc4, locker=3D0x51eadec0, ids=3D0x262f9bc4,= scopes=3D0x26379bc4) at search.c:1099 bdb =3D (struct bdb_info *) 0x20188b98<= br> rc =3D 640653952 depth =3D 3 f =3D {f_choice =3D 160, f_un =3D {f_un_result= =3D 640653996, f_un_desc =3D 0x262f9aac, f_un_ava =3D 0x262f9aac, f_un= _ssa =3D 0x262f9aac, f_un_mra =3D 0x262f9aac, f_un_complex =3D 0x262f9a= ac}, f_next =3D 0x0} rf =3D {f_choice =3D 163, f_un =3D {f_un_resul= t =3D 640654008, f_un_desc =3D 0x262f9ab8, f_un_ava =3D 0x262f9ab8, f_u= n_ssa =3D 0x262f9ab8, f_un_mra =3D 0x262f9ab8, f_un_complex =3D 0x262f9a= b8}, f_next =3D 0x286ef7dc} xf =3D {f_choice =3D 161, f_un =3D {f_un_resul= t =3D 640653972, f_un_desc =3D 0x262f9a94, f_un_ava =3D 0x262f9a94, f_u= n_ssa =3D 0x262f9a94, f_un_mra =3D 0x262f9a94, f_un_complex =3D 0x262f9a= 94}, f_next =3D 0x0} nf =3D {f_choice =3D 0, f_un =3D {f_un_result = =3D 0, f_un_desc =3D 0x0, f_un_ava =3D 0x0, f_un_ssa =3D 0x0, f_un_mra = =3D 0x0, f_un_complex =3D 0x0}, f_next =3D 0x262f9aa0} stack =3D (ID *) 0x1020cc58 aa_ref =3D {aa_desc =3D 0x200c0268, aa_value =3D= {bv_len =3D 8, bv_val =3D 0x102dbf2c "r\ef\erral"}}<b= r> sf =3D {f_choice =3D 0, f_un =3D {f_un_result = =3D 641440756, f_un_desc =3D 0x263b9bf4, f_un_ava =3D 0x263b9bf4, f_un_= ssa =3D 0x263b9bf4, f_un_mra =3D 0x263b9bf4, f_un_complex =3D 0x263b9b= f4}, f_next =3D 0x262f9ad0} aa_subentry =3D {aa_desc =3D 0x0, aa_value =3D= {bv_len =3D 0, bv_val =3D 0x0}} bv_ref =3D {bv_len =3D 8, bv_val =3D 0x102dbf2= c "r\ef\erral"} #8 0x10228ee4 in bdb_search (op=3D0x243de2d8, rs=3D0x= 263ba824) at search.c:578 bdb =3D (struct bdb_info *) 0x20188b98<= br> id =3D 0 cursor =3D 0 lastid =3D 4294967295 candidates =3D {0 <repeats 131072 times>= } scopes =3D {0 <repeats 63759 times>, 641= 435536, 0, 0, 0, 0, 4030840384, 0 <repeats 11 times>, 641435684, = 0 <repeats 206 times>, 641434560, 0 <repeats 11 times>, 641434656, 0, 0, 0, 6414= 34656, 4030840384, 3490904144, 0, 0, 4030840384, 0, 0, 0, 0, 0, 0, 6414= 34672, 0, 0, 0, 32, 58, 22528, 0, 0, 11, 58, 4030431112, 641434720, 25672581= 80, 3490905504, 0, 641434768, 4030840384, 4112, 0, 4030805596, 40304268= 72, 608034984, 959840256, 110, 608035812, 0, 0, 641434800, 0, 34909= 02496, 0, 641434800, 4030840384, 58, 22528, 0, 144, 0, 269721729, 26972= 1729, 4030854004, 3490917464, 0, 641434880, 4112, 58, 4030431112, 6414= 34880, 4030840384, 3490883944, 0, 641434896, 4030840384, 3490889600, 64= 1435752, 641434896, 4030840384, 3491274292, 0, 0, 641437345, 641437340, = 1, 0, 1, 4030431112, 4030431112, 641434960, 0, 3490885628, 641435752, 6= 41435008, 4030840384, 3491268044, 0, 641434976, 4030840384, 0, 0, 641434992= , 0, 0, 641435752, 641435008, 4031927728, 3491274292, 608035800, 641435= 072, 297, 3490878276, 0, 641435072, 4030840384, 3490889836, 0,= 641435072, 4030840384, 3490889600, 641435752, 641435648, 4030840384, 3= 491266240, 0, 0, 4030840384, 0, 14, 32, 608035800, 0, 0, 0, 0, 14, 14= , 641435168, 0, 3490878896, 0, 0, 4030840384, 0 <repeats 11 times&gt= ;, 608035800, 1, 0, 641437088...} e =3D (Entry *) 0x0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 6= 78360812, bv_val =3D 0x23a301e0 ""}, e_nname =3D {bv_len =3D = 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc=3Dsozv\ers= ,dc=3Dat"}, e_attrs =3D 0x3, e_ocflags =3D 641440736, e_bv =3D {bv= _len =3D 641440832, bv_val =3D 0xf041be40 ""}, e_private =3D 0x203a0f78} e_root =3D (Entry *) 0x2035880c matched =3D (Entry *) 0x0 ei =3D (EntryInfo *) 0x203a0f78 attrs =3D (AttributeName *) 0x0 realbase =3D {bv_len =3D 23, bv_val =3D 0x243e= 94e8 "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"} mask =3D 5119 stoptime =3D 1239955337 manageDSAit =3D 0 tentries =3D 0 nentries =3D 0 idflag =3D 0 locker =3D 0x51eadec0 lock =3D {off =3D 0, ndx =3D 412, gen =3D 7777= 0, mode =3D DB_LOCK_READ} opinfo =3D (struct bdb_op_info *) 0x0<b= r> ltid =3D (DB_TXN *) 0x0 oex =3D (OpExtra *) 0x0 stub =3D {bv_len =3D 4030851424, bv_val =3D 0x= 0} #9 0x100d66dc in overlay_op_walk (op=3D0x243de2d8, rs= =3D0x263ba824, which=3Dop_search, oi=3D0x20189d68, on=3D0x0) at backove= r.c:646 func =3D (BI_op_bind **) 0x200012b4 = rc =3D 32768 sc_next =3D (slap_callback *) 0x0 #10 0x100d691c in over_op_func (op=3D0x243de2d8, rs=3D= 0x263ba824, which=3Dop_search) at backover.c:698 oi =3D (slap_overinfo *) 0x20189d68 = on =3D (slap_overinst *) 0x20189e78 = be =3D (BackendDB *) 0x20187f68 db =3D {bd_info =3D 0x20001288, bd_self =3D 0x= 20187f68, be_ctrls =3D "\000\001\001\001\000\001\000\000\= 001\000\000\001\001\000\001", '\0' <repeats 17 times>, &quot= ;\001", be_flags =3D 2312, be_restrictops =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, ss= s_transport =3D 0, sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0,= sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_s= imple_bind =3D 0}, be_suffix =3D 0x20183b08, be_nsuffix =3D 0x20189a28,= be_schemadn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, b= v_val =3D 0x0}, be_rootdn =3D {bv_len =3D 34, bv_val =3D 0x20189ce8 "cn=3DManag\er,dc=3Dpva= ,dc=3Dsozv\ers,dc=3Dat"}, be_rootndn =3D {bv_len =3D 34,<br= > bv_val =3D 0x20189d38 "cn=3Dmanag\er,dc=3Dpva= ,dc=3Dsozv\ers,dc=3Dat"}, be_rootpw =3D {bv_len =3D 5, bv_val =3D = 0x20187138 "start"}, be_max_deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D= 0, lms_s_soft =3D -1, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_= pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D= 0x2016b768, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D = 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x20= 356508, be_pcl_mutex =3D {__mt_word =3D {0, 0, 0, 1, 0, 1373, 0, 5, 0, = 0, 0, 0, 0}}, be_pcl_mutexp =3D 0x20188034, be_syncinfo =3D 0x0, b= e_pb =3D 0x0, be_cf_ocs =3D 0x2001b2a8, be_private =3D 0x20188b98, be_n= ext =3D {stqe_next =3D 0x20192308}} cb =3D {sc_next =3D 0x0, sc_response =3D @0x20= 01e51c: 0x100d553c <over_back_response>, sc_cleanup =3D @0x0: 0x1= , sc_private =3D 0x20189d68} rc =3D 32768 #11 0x100d6a84 in over_op_search (op=3D0x243de2d8, rs=3D= 0x263ba824) at backover.c:720 No locals. #12 0x100b3434 in fe_op_search (op=3D0x243de2d8, rs=3D= 0x263ba824) at search.c:366 bd =3D (BackendDB *) 0x20046498 entry =3D (Entry *) 0x1021638 #13 0x100b2b2c in do_search (op=3D0x243de2d8, rs=3D0x2= 63ba824) at search.c:217 base =3D {bv_len =3D 23, bv_val =3D 0x243e93ff= "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"} siz =3D 0 off =3D 0 i =3D 0 dummy =3D 0x5469746c <Address 0x5469746c ou= t of bounds> #14 0x1006c154 in connection_operation (ctx=3D0x263ba9= 5c, arg_v=3D0x243de2d8) at connection.c:1084 rc =3D 80 op =3D (Operation *) 0x243de2d8 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, = sr_msgid =3D 0, sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_r= ef =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D { sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D= {r_rspoid =3D 0x0, r_rspdata =3D 0x0}, sru_search =3D {r_entry =3D 0x0= , r_attr_flags =3D 0, r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_= nentries =3D 0, r_v2ref =3D 0x0}}, sr_flags =3D 0} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D (Connection *) 0x201bd448 memctx =3D (void *) 0x243de6b8 memctx_null =3D (void *) 0x0 memsiz =3D 1048576 curelm =3D (struct Operation *) 0x1 = #15 0x1006c848 in connection_read_thread (ctx=3D0x263b= a95c, argv=3D0x20) at connection.c:1211 rc =3D 0 cri =3D {op =3D 0x243de2d8, func =3D @0x0: 0x1= , arg =3D 0x0, ctx =3D 0x263ba95c, nullop =3D 0} s =3D 32 #16 0xd26daf88 in ldap_int_thread_pool_wrapper (xpool=3D= 0x200c9588) at tpool.c:663 pool =3D (struct ldap_int_thread_pool_s *) 0x2= 00c9588 task =3D (ldap_int_thread_task_t *) 0x23e43ae8= work_list =3D (ldap_int_tpool_plist_t *) 0x200= c961c ctx =3D {ltu_id =3D 1286, ltu_key =3D {{ltk_ke= y =3D 0x2001e2ac, ltk_data =3D 0x243de5a8, ltk_free =3D @0x2001e2b8: 0x= 1006b814 <conn_counter_destroy>}, {ltk_key =3D 0x2001e048, ltk_data =3D 0x243de6b8, = ltk_free =3D @0x2001e054: 0x1000a1e4 <slap_sl_mem_destroy>}, {ltk= _key =3D 0x20020b20, ltk_data =3D 0x0, ltk_free =3D @0x20020b2c: 0x10= 009864 <slap_op_q_destroy>}, {ltk_key =3D 0x20356518, ltk_data =3D= 0x51eadec0, ltk_free =3D @0x200201fc: 0x1020f550 <bdb_loc= ker_id_free>}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D @0x0= : 0x1} <repeats 28 times>}} kctx =3D (ldap_int_thread_userctx_t *) 0x0</fo= nt> i =3D 32 keyslot =3D 171 hash =3D 171 ptr_ =3D (const unsigned char *) 0x263ba95c &q= uot;" i_ =3D 4 #17 0xd048fc50 in _pthread_body () from /usr/lib/libpt= hread.a(shr_xpg5.o) No symbol table info available. Mit freundlichen Gr=FC=DFen<= b> Howard ALLISON <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"95"><img src=3D"cid:1__=3D4EBBFF08DFA38= 8418f9e8a93d(a)pva.sozvers.at" width=3D"83" height=3D"52"></td><td width=3D= "237" valign=3D"middle">Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: <a href=3D"mailto:howard.allison@pva.sozvers.at"><f= ont size=3D"2" color=3D"#0000FF" face=3D"MS Sans Serif">howard.allison@= pva.sozvers.at</a><b= r> Internet: <a href=3D"http://www.pensionsversicherung.at/"><fo= nt size=3D"2" color=3D"#0000FF" face=3D"MS Sans Serif">www.pensionsvers= icherung.at</a></td></tr> </table> -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen = bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the indiv= iduality or entity to which it is addressed and may contain information that is pri= vileged, confidential and exempt from disclosure. If you are not the intended re= cipient you are notified that any dissemination, distribution, use or copying of this c= ommunication is strictly prohibited. If you received this message in error, please imme= diately destroy this message. -------------------------- </body></html>= --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841-- --0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: image/gif; name="18476766.gif" Content-Disposition: inline; filename="18476766.gif" Content-ID: <1__=4EBBFF08DFA388418f9e8a93d(a)pva.sozvers.at> Content-transfer-encoding: base64 R0lGODlhUwA0APcAAA4Rm9DR2jw/qpaYw3Z4sx4hoLy9zldZsIGDtTEzpbGyztbe3lBSr6ipyY+R vDg7p2xursnL1UZJqhgaoSosoEFDpsTF1dLT2hganp+iwIaIwmNmqyEpnGxvtnt8vbe40sHC0aap z1VXsklLpoeJuxwfn46QxZmZzF1fsdHS2WxuuTQ3piAjoSotpL6/09zd3kxPrRQXnVVYpmdptoqN vczMzKutzj0/p7i60nFztVRXrHp7tJqdwKqrxlpdskJFrJKUvn+AumJktdfY3LW2zYKFvZKUxqSl xr3F1khLrSQopM3O1igrpGpstpydxNbW1v4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AADYLuB3EgMwABIBAACV8AAAOQA8AAAAAACeAgAAAQAAAIhkWAAgwBUAqAZWAAIAAAC88hIA2Vi0 d9UHAYXk8hIAAgAAACj0EgAc8xIAotfhdxIDMAASAQAAlfAAADkAPAABAAAAEgEAAJXwAAASAzAA SLkVANi1FQAgACAAAAAVACAAIAAAABUARgBlAHIAdABpAGcAAAASAAAAAAD8iOd3AAAAAAAAAADV BwGFiGRYADzzEgDxoeF3EgMwAAIDJwASAQAAlfAAADkAPAAAABMAlfAAAKqHRQASAzAAAgMnAAAB AAAkAAAAOQA8AKEAAACIZFgApPYSABgVOwB3wrR3KAM4AGhWEwAgAQAA2LUVAAAAAAAAAAAA0PMS AJUriHcINoh3/////+DzEgAec+d3AAATAAgAFAAYAQAAbJxIAGibSACJOOh3AAAAAAAAAAAAAAAA AAAAAETaRABsnEgA9MIVAHlWEwB5m0gA/////2hWEwB32EQAbJxIACH5BAEAAFAALAAAAABTADQA QAj/AKEIHEiwoMGDCBMqXMiwYcIhAyRgmEixIgYWD1BosAEiwoUhIIc4hBJBAQ0hK2LE0KFgZMIB Fi22ADEywoyJNA42mWARwcENGDqIJBhgKMMHMZPONFjEYgeDFlpMuJHCIA0nBkEwSTqRREEaSiIk tLB14gAoDWIuLTgkgFu3LpygYMGTKxCEBOomDWIQJgAPLgewyNHQQhAdD1hwpaiycYkEhKGAqHrw QsQJE5QUCeCys+fPoEMvHBKXAGIlJVJjXjyxBIUbKIo0sCDaJQm6rHPr5lrAAMMIRIwyHAJDL9e1 nSFgaFkwAgXMP4QLhGmRCc2BATZcT5hgN/KRRBRT/9wwGgbrB0sKQpgQOWGAG5iPEBwCJEEBFwad xNgdk4XvgQ2UUN0O6RVkgASY+XBBbdJBMcQHNORAwABERNDgQhdYoIAJTVRQgkos6ECDCxfWZuKJ KIL2AQFI8TcRC0wkkMADNNLYAgsCVlTACCRslyJBNuWoWwEuUtSCBB04QZtCCnQgAQ2UfTbEDMZR VIAPMwih5ZZc+pBEWRMl0ASXWpqXlHw/EiTDfot955AQMWRg0BAjVITCQU1RNINwRGDFUBBVKuWj QDSUwMKhK/RgkAuHLklQDxgo4ehACghZUQJiYXeDotx5N6iDKYQaZUFO5AhDiUStwFpOBDkBgAkJ of+glw0osFmRmwsFgEJSgMUaKEUrZDrQERgAwBxCH4h3p0BHPIcZrgPYWmQDBgHxawFeNYcgAGc5 dIRi1DYUbZGXZkpEaiVIEMSnJHWQIw2oNgTCBuGmudASRzTRgkqQsWsvQhd8AEQODDzQQgFEWqRS ai3ccEAOAyhgQbz/VmzxxRhn7FAALjQAxA5CyMAADEmUnIQOKHRQxAAcLaixSwE0kMOX5LLWgg4k BPfyQBc4cYB4uSUggRBBsIyDBREsofTSFuBgwwBFzDBCdy/OcOy/R5hpsxAEEDDDAUnc8MAKZD9w gwQ6COEBEDZMrNAFRARRAQVC/HfiESv8WrN3OBf/iJAFJCCAH2hDdKD33kUuazEB0lZEgbAPgVDE A5itwFlzVFd0g8sEEdFtbQYoYbO/CeW1uUE2WGodVC1MhALnUKTQA8UANq4W6WOxAMNBNGAWn0Ep 3GBRtgMNgKZC5+qG6xIf4OC83wSlNcNBVE5QxEEMJNWeQA4IsZAOnhpEgkXTF2TBcz6x9cABP+l9 vEAo6KBQ5qP3ZfYNDn/qgugYfD4QSAbZweGu16oY2CAhrVMe7hIiBIqU4IALoc5i6iUQIMRgewVp 0UWaYCkjLdAgF0iCcZRgt4P0oIMW2QFbbvCqhPSOIgoAgRKqhKuEKEBrFrEcQvbHGh4YRAcxYALk /wxyk4kQUDC3+lQDEoC/G6wATKwZQYOWkIBfxWAH0gHBvlgAPbxgJgF+MwD4MIAr/exNcQIZgkRi UgFOAWkEE4iBUBxChBnKz3wkmJRAzLg3AhBkV0bKQQkH4oQqxmAGsPNWDH6QSIQMAACIwwABWZQD G1zoAkBo0Q8gGBob3ABWDkkBCBQwABJ4QAU+0IEqdXAAtRWBbS5YQrwiQIMfYEYJORgcii5whCGS JIa0GwlpBiCEBCwMBgPw5css4IQmwKACN4CBEHJQBCMcoQHYxKYTjFCEHAghCSsoQGOYAAMCNOCD O6tMBFygABs4wQRAiGcInBfLRqbznvjMZ4oCAgA7 --0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841--

1 0

ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by linamat＠telco.md 17 Apr '09

17 Apr '09

I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. According to ITS#5860 slapd should not allocate more memory than it was specified. In fact I have the same behaviour as it was with previous version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for set_cachesize 300 MB). But slapd process continuosly grows in memory until 32-bit limit then crashes due to unavalable memory resources. I need to mention bdb database size is less then 1 GB. After restart it rapidly consumes 1.5 GB RSS in few minutes and then it grows beyond the limit during 24 hours. The more queries are processing the more memory it eats. I am using this database for logging which size grows. The question is: is it possible to use 32-bit openldap with relatively large database sizes that override 32-bit per-process memory space? My slapd.conf contains: threads 64 concurrency 50 cachesize 200000 dncachesize 400000 idlcachesize 600000 shm_key 10 DB_CONFIG: set_cachesize 0 300097152 1 set_lk_max_locks 1000000 set_lk_max_lockers 1000000 set_lk_max_objects 1000000 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 ls -ls ./openldap-data total 1212876 -rw-r--r-- 1 slapd nobody 640 Apr 17 08:42 DB_CONFIG -rw------- 1 slapd nobody 8 Apr 16 10:50 __db.001 -rw-r--r-- 1 slapd nobody 4096 Apr 16 10:50 alock -rw------- 1 slapd nobody 6053888 Apr 17 09:50 cn.bdb -rw------- 1 slapd nobody 1024000 Apr 17 09:50 dhcpHWAddress.bdb -rw------- 1 slapd nobody 96583680 Apr 17 09:50 dn2id.bdb -rw------- 1 slapd nobody 515637248 Apr 17 09:50 id2entry.bdb -rw------- 1 slapd nobody 1343488 Apr 17 09:50 objectClass.bdb Any help would be much appreciated. Regards, Sergey.

1 0

(ITS#6064) syncrepl.c does not compile ("//" comment)
by h.b.furuseth＠usit.uio.no 16 Apr '09

16 Apr '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard C89 chokes on this comment from syncrepl.c 1.445: // add new syncrepl to end of list (same order as when deleting) Fixing.

1 0

Re: (ITS#6063) Syncrepl replication be_modify failed (18)
by michael＠stroeder.com 16 Apr '09

16 Apr '09

wan(a)ccs.neu.edu wrote: > I've been battling some issues with syncrepl for a while now, and I > can't quite figure out what has gone wrong. > [..] > and am still having issues (now at > 2.4.15) Could you please try 2.4.16 released a couple of days ago? There were four syncrepl-related fixes in this release. Not sure whether one of the fixes really solves your particular problem but please give it a try. Maybe it would also help if you try to get more detailed logs by starting slapd with -d on the console. (You might also need to use -u and/or -g option to use the demon user.) Ciao, Michael.

1 0

Re: (ITS#6062) Compile failure in libraries/liblutil/getpeereid.c
by quanah＠zimbra.com 15 Apr '09

15 Apr '09

--On Wednesday, April 15, 2009 5:52 PM +0000 rps2(a)socal.rr.com wrote: > Full_Name: Rick Stevens > Version: 2.4.16 > OS: Fedora 10, x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.200.106.34) > > > Compilation fails when compiling the libraries/liblutil/getpeereid.c > file. Under Fedora 10, one must include the line: > > #define _GNU_SOURCE > > somewhere near the top of the file to ensure the system can pick up the > size of the "ucred" structure. This is a duplicate of ITS#5464 and will be closed. The fix will be in the next release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6063) Syncrepl replication be_modify failed (18)
by wan＠ccs.neu.edu 15 Apr '09

15 Apr '09

Full_Name: Will Nowak Version: 2.4.15 OS: Ubuntu Hardy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.239.45.4) [Creating an ITS issue of the email thread with the same subject] I've been battling some issues with syncrepl for a while now, and I can't quite figure out what has gone wrong. I initially found http://www.openldap.org/lists/openldap-software/200812/msg00040.html which seemed to describe my issue, and it recommended upgrading to openldap 2.4.13. I tried that, and am still having issues (now at 2.4.15). I built the software for ubuntu hardy on i386, available at https://edge.launchpad.net/~compbrain/+archive/ppa/+sourcepub/566951/+listi… The situation involves a master with 3 slaves using syncrepl. A change comes into the master adding a member to a nisNetgroup/groupOfNames hybrid container: dn: cn=friends,ou=netgroup,dc=example,dc=com objectClass: groupOfNames objectClass: nisNetgroup objectClass: top cn: friends member: uid=bobby,ou=people,dc=example,dc=com nisNetgroupTriple: (,bobby,shadow) An incoming add for user james looks like dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com member: uid=james,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) nisNetgroupTriple: (,james,shadow) Up until this point, everything is fine -- all changes made on the master have replicated ok to the slaves. Now, james is not my friend anymore, so he gets removed from the container: dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) At this point, the most recent change gets applied to the master ok, but it does not get replicated to the slaves. They have a be_modify failed in their logs: Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_search (0) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 cn=friends,ou=netgroup,dc=example,dc=com Apr 13 23:05:43 sl1 slapd[30277]: null_callback : error code 0x12 Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify (18) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify failed

1 0

(ITS#6062) Compile failure in libraries/liblutil/getpeereid.c
by rps2＠socal.rr.com 15 Apr '09

15 Apr '09

Full_Name: Rick Stevens Version: 2.4.16 OS: Fedora 10, x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.200.106.34) Compilation fails when compiling the libraries/liblutil/getpeereid.c file. Under Fedora 10, one must include the line: #define _GNU_SOURCE somewhere near the top of the file to ensure the system can pick up the size of the "ucred" structure.

1 0

(ITS#6061) ./configure messups on NDB and Perl backends
by rps2＠socal.rr.com 15 Apr '09

15 Apr '09

Full_Name: Rick Stevens Version: 2.4.16 OS: Fedora 10, x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.200.106.34) The help text in the configure script for OpenLDAP 2.4.16 states: --enable-ndb enable MySQL NDB Cluster backend no|yes|mod [no] ... --enable-perl enable perl backend no|yes|mod [no] Which indicate that, by default, the MySQL Cluster NDB and Perl back-ends will not be built. This is not the case. The system tries to configure those back-ends. The "make depend" completes normally, but the "make" aborts when trying to compile those back-ends. In the case of the Perl back-end, configure does not find the necessary headers and reports that fact, however it does not set flags to block compilation of that module. On a separate identical machine, I did install the items necessary to build those back-ends. However, the system can't find the necessary headers even though they exist. For NDB, one must install the "mysql-devel" RPM. However, the path for finding the headers isn't correct. On Fedora 10, the include path must include "-I/usr/include/mysql/ndb/ndbapi". For Perl, one must install the "perl-devel" RPM, and the path for finding headers must include "-I/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE".

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Yup this works, good work, thanks. > > Seems a tad slow though, do filters like these drastically slow down the > search? It applies some overhead: for each value of each attribute of each entry it needs to check whether the memberOf attr is present; if it is, a berval comparison is needed (compare the length first, and the value in case of match). As usual, it depends on the structure of your data. Also, but this is independent of ACL evaluation, slapo-rwm duplicates each entry as soon as it needs to do some manipulation on it (like massaging the DNs and so). If you notice any significant overhead, you might want to profile the execution of your slapd, to point out what's the actual bottleneck. 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon > it would be a difficult fix? Please test HEAD (or import the latest fixes to servers/slapd/overlays/rwm.[ch] into 2.4.16, if you prefer). You need to add rwm-drop-unrequested-attrs no to your slapo-rwm configuration. I haven't documented this flag yet; I'd wait until the fix is confirmed. 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by hyc＠symas.com 15 Apr '09

15 Apr '09

ando(a)sys-net.it wrote: > David wrote: >> Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon >> it would be a difficult fix? > > On the contrary, it could be relatively simple. I need to further > investigate what's happening, but I could easily reproduce the issue. > I'll be back. Fixing it for back-bdb/hdb is easy enough. For other backends that don't always return whole entries (e.g. back-ldap) there would be more problems. It's an open question whether we care about those at the moment... -- -- 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon > it would be a difficult fix? On the contrary, it could be relatively simple. I need to further investigate what's happening, but I could easily reproduce the issue. I'll be back. 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#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by hyc＠symas.com 14 Apr '09

14 Apr '09

Gavin Henry wrote: > Thanks, I'll review and let you know. > > Gavin. > And while you're at it, please move the slapd config examples back to the end of the slapd config chapters where they originally came from. You can insert references like "for more detailed discussion of access controls go -there-" but the examples need to be in the config chapters. -- -- 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#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by Gavin Henry 14 Apr '09

14 Apr '09

Thanks, I'll review and let you know. Gavin.

1 0

(ITS#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by jonathan＠phillipoux.net 14 Apr '09

14 Apr '09

Full_Name: Jonathan Clarke Version: 2.4 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-20090414.patch.1 Submission from: (NULL) (213.41.243.192) Hi, As noticed with Gavin on IRC, the Admin Guide doesn't have any obvious instructions on converting from old file format slapd.conf to new cn=config directory based conf - these instructions are only in the slapd-config(8) man page. Please see above patch for a suggestion to incorporating it into the admin guide. I have taken some liberties with the formatting, please feel free to amend if you like. I did put this in a top-level (H2) section, although it's short, mainly to make it obvious in the guide's contents. Any feedback is most welcome, particularly if this needs to be more detailed :) Regards, Jonathan

1 0

(ITS#6059) Abandon syncprov race condition?
by rein＠OpenLDAP.org 14 Apr '09

14 Apr '09

Full_Name: Rein Tollevik Version: 2.4.16 OS: linux URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein I've had two cases where a delete operation was performed on the master without being replicated to its consumers, which so far appear to be cases of possible connection lost (abandon) race conditions. The log (level: stats) shows the "DEL" message of the entry, immediately followed by a "closed (connection lost)" message on the connection. Note: No "RESULT" message was logged. I haven't looked very much into this, but my theory so far is that syncprov skipped replicating of the delete op after noticing the abandon resulting from loosing the connection, even though the delete had already taken place in the local database. That it happened after a delete op might very well have been a coincident, this possible race could exist after any modify op for all I know. Do we need some sort of o_committed flag that can be used to prevent o_abandon from being set or acted upon? Or handle o_abandon more like o_cancel, i.e with multiple values, including "too late"? Rein Tollevik Basefarm AS

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by ando＠sys-net.it 14 Apr '09

14 Apr '09

abartlet(a)samba.org wrote: >> The only problem I see in defining such an attribute is that its >> syntax should allow the value of any syntax, so it should probably be >> octetString or something like that. =20 > > I think the AD document I reference explains that only some attributes > can be an RDN, so it limits them to those with a unicode string > representation I suppose.=20 OK, I coulnd't follow up to the document you cited. > There is another attribute that follows the 'type' of RDN btw (never > seen it used, but it's in the docs).=20 > >> From the implementation point of view, what operations should it be >> used for? If you only need it to be returned with searches, and to be >> compared, then the implementation would be trivial (it could be >> dynamically generated, much like entryDN, as far as I can tell). If >> you need to search for it, namely use it in a filter, then it might be >> better to store it in the database. This would require to handle add >> and modrdn, forbid modify, and nothing else. > > Like entryDN, we need to be able to search on it, so it should probably > be persistent. Ok. Unlike entryDN, which is not persistent but evaluated on the fly based on dn2id indexes, unless we hardcode this in slapd (don't think so) we need to make the attr persistent. It's on the todo list. 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 14 Apr '09

14 Apr '09

David wrote: > So, we're still in dispute, as far as if this is a real bug or not? It seems to be a bug in the design of how data is gathered in view of ACL evaluation. Or better, overlay design invalidated an assumption that was valid when the only database type available passed the entire entry to ACL evaluation *before* entry massaging. Yes, it's a bug. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs