openldap-bugs

openldap-bugs@openldap.org

1 participants
21105 discussions

Re: (ITS#5163) slapd segfaults when running as proxy-caching server
by ando＠sys-net.it 02 Oct '07

02 Oct '07

> While running slapd as a proxy-caching server, it sometimes falls over > with a > signal 11 segfault. I haven't been able to reproduce this and it can > occur when > the system is quiet and nothing much running.... I think this issue has been already fixed, incidentally, in HEAD/re24, but went unnoticed in re23. You should replace the call to ch_malloc() that's around line 1140 in servers/slapd/overlays/pcache.c with a call to ch_calloc(); something like *new_attrs = (AttributeName*)ch_calloc( count + 1, sizeof(AttributeName)); (sorry, I can't access the network right now but by webmail). In fact, right now, the array of AttributeName "new_attrs" is accessed by an_find() while not yet NULL terminated. Please check and report (to create the problem, you need to use filters that contain the attributes that will be cached). 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5163) slapd segfaults when running as proxy-caching server
by toby＠inf.ed.ac.uk 02 Oct '07

02 Oct '07

Full_Name: Toby Blake Version: 2.3.38 OS: Fedora Core 5/6 URL: Submission from: (NULL) (129.215.218.33) While running slapd as a proxy-caching server, it sometimes falls over with a signal 11 segfault. I haven't been able to reproduce this and it can occur when the system is quiet and nothing much running.... Core was generated by `/usr/sbin/slapd -h ldap:///'. Program terminated with signal 11, Segmentation fault. #0 0x008314f3 in strcasecmp () from /lib/libc.so.6 Here's the db portion of slapd.conf: database ldap suffix dc=inf,dc=ed,dc=ac,dc=uk rootdn uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth uri "ldap://testdir.inf.ed.ac.uk/" idassert-bind mode=none bindmethod=sasl saslmech=GSSAPI idassert-authzFrom "dn:*" overlay pcache proxycache bdb 5000 2 500 300 proxycachequeries 10000 proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass afsHomeDirectory primaryRoles secondary Roles proxyattrset 1 cn userPassword memberUid uniqueMember gidNumber nisNe tgroupTriple memberNisNetgroup objectClass proxytemplate (uid=) 0 1800 1800 proxytemplate (&(objectClass=)(uid=)) 0 1800 1800 proxytemplate (&(objectClass=)(cn=)) 1 1800 1800 proxytemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 1800 proxytemplate (&(objectClass=)(uniqueMember=)) 0 1800 1800 proxytemplate (&(objectClass=)(memberUid=)) 0 1800 1800 proxytemplate (&(objectClass=)(uidNumber=)) 0 1800 1800 proxytemplate (&(objectClass=)(gidNumber=)) 1 1800 1800 directory /var/openldap-data dbconfig set_cachesize 0 16777216 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 include /etc/openldap/slapd.conf.indices And, here's the full backtrace from gdb... #0 0x008314f3 in strcasecmp () from /lib/libc.so.6 No symbol table info available. #1 0x0809c83d in an_find (a=0xb0c412d0, s=0xad1f8994) at ad.c:842 No locals. #2 0x08117321 in pcache_op_search (op=0xb0c271b8, rs=0xad6f91c4) at pcache.c:1150 cb = <value optimized out> on = (slap_overinst *) 0x8a4f9d0 cm = (cache_manager *) 0x8a4fac0 qm = (query_manager *) 0x8a6aed8 i = <value optimized out> filter_attrs = (AttributeName *) 0xad1f896c query = {filter = 0xb0c3d178, attrs = 0xb0c411b8, save_attrs = 0xad1f88cc, base = {bv_len = 24, bv_val = 0xad1f81e4 "dc=inf,dc=ed,dc=ac,dc=uk"}, scope = 2} attr_set = 0 template_id = 3 answerable = <value optimized out> cacheable = 1 fattr_cnt = 3 fattr_got_oc = 1 tempstr = {bv_len = 47, bv_val = 0xad1f88fc "(&(objectClass=)(|(memberUid=)(uniqueMember=)))"} #3 0x080bb404 in overlay_op_walk (op=0xb0c271b8, rs=0xad6f91c4, which=op_search, oi=0x8a4f8e0, on=0x8a4f9d0) at backover.c:639 rc = -1329434184 #4 0x080bb89d in over_op_func (op=0xb0c271b8, rs=0xad6f91c4, which=op_search) at backover.c:701 oi = (slap_overinfo *) 0x8a4f8e0 on = (slap_overinst *) 0x8a4f9d0 be = (BackendDB *) 0x8a4f4c8 db = {bd_info = 0x8a4f9d0, be_ctrls = "\000", '\001' <repeats 14 times>, '\0' <repeats 17 times>, "\001", be_flags = 257, be_restrictops = 0, be_requires = 0, be_ssf_set = { sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x8a6af10, be_nsuffix = 0x8a6ade0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 64, bv_val = 0x8a4f838 "uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth"}, be_rootndn = {bv_len = 64, bv_val = 0x8a4f898 "uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 24576, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x8a6a6c0, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8aa4820, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x8a4f598, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81cd360, be_private = 0x8a4f5d0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x80bb180 <over_back_response>, sc_cleanup = 0, sc_private = 0x8a4f8e0} rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #5 0x0806316f in fe_op_search (op=0xb0c271b8, rs=0xad6f91c4) at search.c:355 entry = (Entry *) 0xad6f8118 bd = (BackendDB *) 0x81d1240 #6 0x08063b21 in do_search (op=0xb0c271b8, rs=0xad6f91c4) at search.c:217 base = {bv_len = 24, bv_val = 0xb0c40440 "dc=inf,dc=ed,dc=ac,dc=uk"} siz = 1 i = 1 #7 0x080611f9 in connection_operation (ctx=0xad6f9238, arg_v=0xb0c271b8) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = (Connection *) 0xb6885288 memctx = (void *) 0x8b0c630 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #8 0x08131fd3 in ldap_int_thread_pool_wrapper (xpool=0x8a324f8) at tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0xb0c16600 ltc_key = {{ltk_key = 0x80ac320, ltk_data = 0x8b0c630, ltk_free = 0x80ac210 <slap_sl_mem_destroy>}, {ltk_key = 0x8aa5430, ltk_data = 0x9b, ltk_free = 0x80e9550 <bdb_locker_id_free>}, { ltk_key = 0x80c9170, ltk_data = 0xac9f7008, ltk_free = 0x80c9230 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>} tid = 2909772688 i = 583 hash = <value optimized out> #9 0x0093945b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #10 0x0089123e in clone () from /lib/libc.so.6 No symbol table info available. (gdb) Please let me know if any more deugging information would be useful. Cheers Toby Blake University of Edinburgh

1 0

(ITS#5162) Bus Error - core dumped
by piotr.tarnowski＠us.edu.pl 02 Oct '07

02 Oct '07

Full_Name: Piotr Tarnowski (DrFugazi) Version: 2.3.38 OS: Solaris 10 U4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.158.96.61) Hello, I compiled the newest version of OpenLDAP (2.3.38) on Solaris 10 U4 (8/07) system. I tried many times with many compilation options, but I still have an error with 'gmake test': >>>>> Starting test001-slapadd ... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve all the entries... Waiting 5 seconds for slapd to start... 4378 Bus Error - core dumped Waiting 5 seconds for slapd to start... ------------ In tests/testrun/slapd.1.log I found: daemon: select: listen=8 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read activity on 12 connection_get(12) connection_get(12): got connid=0 connection_read(12): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 60 07 02 0....`.. ldap_read: want=6, got=6 0000: 01 03 04 00 80 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x001cbef0 ptr=0x001cbef0 end=0x001cbefc len=12 0000: 02 01 01 60 07 02 01 03 04 00 80 00 ...`........ ber_get_next ldap_read: want=8 error=Resource temporarily unavailable daemon: select: listen=8 active_threads=0 tvp=NULL do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x001cbef0 ptr=0x001cbef3 end=0x001cbefc len=9 0000: 60 07 02 01 03 04 00 80 00 `........ ber_scanf fmt (m}) ber: ber_dump: buf=0x001cbef0 ptr=0x001cbefa end=0x001cbefc len=2 0000: 00 00 .. >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 conn=0 op=0 BIND dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush: 14 bytes to sd 12 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ conn=0 op=0 RESULT tag=97 err=0 text= do_bind: v3 anonymous bind daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read activity on 12 connection_get(12) connection_get(12): got connid=0 connection_read(12): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 30 36 02 01 02 63 31 04 06...c1. ldap_read: want=48, got=48 0000: 11 64 63 3d 65 78 61 6d 70 6c 65 2c 64 63 3d 63 .dc=example,dc=c 0010: 6f 6d 0a 01 02 0a 01 00 02 01 00 02 01 00 01 01 om.............. 0020: 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ...objectclass0. ber_get_next: tag 0x30 len 54 contents: ber_dump: buf=0x001acdd8 ptr=0x001acdd8 end=0x001ace0e len=54 0000: 02 01 02 63 31 04 11 64 63 3d 65 78 61 6d 70 6c ...c1..dc=exampl 0010: 65 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 e,dc=com........ 0020: 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 .........objectc 0030: 6c 61 73 73 30 00 lass0. ber_get_next do_search ldap_read: want=8 error=Resource temporarily unavailable ber_scanf fmt ({miiiib) ber: ber_dump: buf=0x001acdd8 ptr=0x001acddb end=0x001ace0e len=51 0000: 63 31 04 11 64 63 3d 65 78 61 6d 70 6c 65 2c 64 c1..dc=example,d 0010: 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 00 02 01 c=com........... 0020: 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 ......objectclas 0030: 73 30 00 s0. daemon: select: listen=8 active_threads=0 tvp=NULL >>> dnPrettyNormal: <dc=example,dc=com> => ldap_bv2dn(dc=example,dc=com,0) <= ldap_bv2dn(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> SRCH "dc=example,dc=com" 2 0 0 0 0 begin get_filter PRESENT ber_scanf fmt (m) ber: ber_dump: buf=0x001acdd8 ptr=0x001acdff end=0x001ace0e len=15 0000: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ..objectclass0. end get_filter 0 filter: (objectClass=*) ber_scanf fmt ({M}}) ber: ber_dump: buf=0x001acdd8 ptr=0x001ace0c end=0x001ace0e len=2 ----------- Output from truss: (...) 26487/3: write(2, " b d b _ d n 2 e n t r y".., 34) = 34 26487/3: write(2, " = > b d b _ d n 2 i d".., 34) = 34 26487/3: write(2, " < = b d b _ d n 2 i d".., 32) = 32 26487/3: Incurred fault #5, FLTACCESS %pc = 0x7E72B4D0 26487/3: siginfo: SIGBUS BUS_ADRALN addr=0x00000032 26487/3: Received signal #10, SIGBUS [default] 26487/3: siginfo: SIGBUS BUS_ADRALN addr=0x00000032 26392: waitid(P_PID, 26517, 0xFFBFF5C0, WEXITED|WTRAPPED|WNOWAIT) (sleeping...) (...) ------------- Is this a software error, or compiler/system issue ? I use Sun Studio 12 on sparc. Machine hardware: sun4u OS version: 5.10 Processor type: sparc Hardware: SUNW,Sun-Fire-V890 The following components are installed on your system: Sun Studio 12 Sun Studio 12 C Compiler Sun Studio 12 C++ Compiler Sun Studio 12 Tools.h++ 7.1 Sun Studio 12 C++ Standard 64-bit Class Library Sun Studio 12 Garbage Collector Sun Studio 12 Fortran 95 Sun Studio 12 Debugging Tools (including dbx) Sun Studio 12 IDE Sun Studio 12 Debugger GUI Sun Studio 12 Performance Analyzer (including collect, ...) Sun Studio 12 X-Designer Sun Studio 12 VIM editor Sun Studio 12 XEmacs editor Sun Studio 12 Performance Library Sun Studio 12 LockLint Sun Studio 12 Building Software (including dmake) Sun Studio 12 Documentation Set Sun Studio 12 /usr symbolic links and GNOME menu item version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95 8.3 SunOS_sparc Patch 127000-01 2007/07/18 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx Debugger 7.6 SunOS_sparc Patch 124872-02 2007/08/16 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun Analyzer 7.6 SunOS_sparc Patch 126995-01 2007/07/17 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun Distributed Make 7.8 SunOS_sparc Patch 126503-01 2007/07/19 Regards -- Piotr (DrFugazi) Tarnowski

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 01 Oct '07

01 Oct '07

--On Tuesday, October 02, 2007 2:35 AM +0000 hyc(a)symas.com wrote: > quanah(a)zimbra.com wrote: >> --On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: >> >>> The following files will be uploaded to the ftp site, where # will be >>> the assigned ITS number. >> >> URL's specifically are: >> >> <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> >> <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> >> <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> > > The pstack output is a bit odd, is this a regular debug build? With frame > pointers, etc? Can you get a stack trace in gdb? It is a regular build, and they killed and restarted it before getting any gdb information. We've asked them to please get the gdb information in the future. Since it has happened twice now for thi particular group in about a month, I'm hopeful it'll happen again before too long. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by hyc＠symas.com 01 Oct '07

01 Oct '07

quanah(a)zimbra.com wrote: > --On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: > >> The following files will be uploaded to the ftp site, where # will be the >> assigned ITS number. > > URL's specifically are: > > <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> > <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> > <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> The pstack output is a bit odd, is this a regular debug build? With frame pointers, etc? Can you get a stack trace in gdb? -- -- 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

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 01 Oct '07

01 Oct '07

--On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: > The following files will be uploaded to the ftp site, where # will be the > assigned ITS number. URL's specifically are: <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 01 Oct '07

01 Oct '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.104.138.6) Several customers have found delta-syncrepl will lock up after a time. Today it occurred again, and this time some logging data was able to be gathered. The last operation logged was a MOD op. This matches past lockups, which were also either MOD or ADD operations. The following files will be uploaded to the ftp site, where # will be the assigned ITS number. #-dbstat.delta.out.2007-10-01 which is the db_stat information for the accesslog DB #-db_stat.out.2007-10-01 which is the db_stat information for the main DB #-pstak.out.2007-10-01 which is the pstack information for the slapd process Unfortunately no GDB info was retrieved this time, and reportedly gcore hung. The most interesting part is I see no WRITE locks held in either DB, and all the client threads are hung in a mutex.

1 0

Re: (ITS#5160) syncrepl of glued and syncrepl'd databases causes unwanted deletes on the end consumer
by hyc＠symas.com 01 Oct '07

01 Oct '07

jclarke(a)linagora.com wrote: > I have tested this on both 2.3.38 and HEAD (same version on all 3 servers), and > behaviour is quite different, though the end result is the same. Due to multiple limitations, this is not expected to work in 2.3 at all. > On HEAD, things are quite different: > request done: ld 0x82c2228 msgid 2 > do_syncrep2: rid=7 LDAP_RES_SEARCH_RESULT > nonpresent_callback: rid=7 got UUID b5797e8c-0486-102c-83e0-79137da6179f, dn > dc=ossa,dc=linagora,dc=org > nonpresent_callback: rid=7 got UUID b5a2f834-0486-102c-83e1-79137da6179f, dn > uid=root,dc=ossa,dc=linagora,dc=org > nonpresent_callback: rid=7 got UUID b5a31526-0486-102c-83e2-79137da6179f, dn > uid=replicator,dc=ossa,dc=linagora,dc=org > adresse de be_modify : 80c8840 > null_callback : error code 0x32 > syncrepl_updateCookie: rid=7 be_modify failed (50) This is Insufficient Access. You have not configured the glue databases with identical rootDN's, which is clearly documented as a requirement for glued databases. -- -- 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#5160) syncrepl of glued and syncrepl'd databases causes unwanted deletes on the end consumer
by jclarke＠linagora.com 01 Oct '07

01 Oct '07

Full_Name: Jonathan Clarke Version: 2.3.38 and HEAD (but with slightly different results) OS: Linux URL: ftp://ftp.openldap.org/incoming/unwanted-deletes-syncrepl-glue.tar.gz Submission from: (NULL) (213.41.243.192) Hi folks, I've come across an issue with a server using the glue overlay with one of it's subordinate databases syncrepl'd. There are two problems: 1) updating the root database's contextCSN 2) when replicating this whole server with syncrepl (to a 3rd server), certain updates cause many entries to be deleted from the consumer. The following "schema" should describe this setup more clearly (names TOP, MIDDLE and BOTTOM are for easy reference): TOP: |----------------------------| | One bdb backend: | | dc=ossa,dc=linagora,dc=org | |----------------------------| | MIDDLE: | |-------------------------------| | Two bdb backends + glue: | | 1) dc=ossa,dc=linagora,dc=org | | subordinate | | syncrepl from above server | | 2) dc=linagora,dc=org | | 'master' for this branch | | | | syncprov overlay | |-------------------------------| | BOTTOM: | |-------------------------------| | One bdb backend: | | dc=linagora,dc=org | | syncrepl from above server | |-------------------------------| All config files, and some sample data sets, are in the archive at the URL above. I have tested this on both 2.3.38 and HEAD (same version on all 3 servers), and behaviour is quite different, though the end result is the same. On 2.3.38: 1) Set up all three servers, make sure they're sync'ed. 2) Modify some attribute on the TOP server (I add a description to the root DN, dc=ossa,dc=linagora,dc=org) 3) Watch this modification propagate to the middle server. the contextCSN in dc=linagora,dc=org is not updated, but the one in dc=ossa,dc=linagora,dc=org is (equals to the entryCSN of the entry I modified). The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- request done: ld 0x822ec20 msgid 1 do_syncrep2: rid 007 LDAP_RES_INTERMEDIATE - SYNC_ID_SET syncrepl_entry: rid 007 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 007 be_search (0) syncrepl_entry: rid 007 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid 007 be_modify (0) request done: ld 0x822ec20 msgid 2 do_syncrep2: rid 007 LDAP_RES_SEARCH_RESULT 8>--------------------------------------------------------------- 4) Watch the BOTTOM server (see schema above) do it's syncrepl and delete some entries below the glued database (glued on MIDDLE server, not on this one). The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- request done: ld 0x822a320 msgid 1 request done: ld 0x822a320 msgid 2 do_syncrep2: rid 888 LDAP_RES_SEARCH_RESULT request done: ld 0x822a320 msgid 1 do_syncrep2: rid 888 LDAP_RES_INTERMEDIATE - SYNC_ID_SET syncrepl_entry: rid 888 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 888 be_search (0) syncrepl_entry: rid 888 dc=linagora,dc=org syncrepl_entry: rid 888 be_modify (0) syncrepl_entry: rid 888 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 888 be_search (0) syncrepl_entry: rid 888 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid 888 be_modify (0) request done: ld 0x822a320 msgid 2 do_syncrep2: rid 888 LDAP_RES_SEARCH_RESULT syncrepl_del_nonpresent: rid 888 be_delete uid=replicator,dc=ossa,dc=linagora,dc=org (0) syncrepl_del_nonpresent: rid 888 be_delete uid=root,dc=ossa,dc=linagora,dc=org (0) 8>--------------------------------------------------------------- On HEAD, things are quite different: 1) Start the TOP server. 2) Start the MIDDLE server. Errors happen immediatly, on first sync attempt. The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- slapd starting request done: ld 0x82c2228 msgid 1 syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5797e8c-0486-102c-83e0-79137da6179f syncrepl_entry: rid=7 be_search (32) syncrepl_entry: rid=7 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a2f834-0486-102c-83e1-79137da6179f syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=root,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a31526-0486-102c-83e2-79137da6179f syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=replicator,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) request done: ld 0x82c2228 msgid 2 do_syncrep2: rid=7 LDAP_RES_SEARCH_RESULT nonpresent_callback: rid=7 got UUID b5797e8c-0486-102c-83e0-79137da6179f, dn dc=ossa,dc=linagora,dc=org nonpresent_callback: rid=7 got UUID b5a2f834-0486-102c-83e1-79137da6179f, dn uid=root,dc=ossa,dc=linagora,dc=org nonpresent_callback: rid=7 got UUID b5a31526-0486-102c-83e2-79137da6179f, dn uid=replicator,dc=ossa,dc=linagora,dc=org adresse de be_modify : 80c8840 null_callback : error code 0x32 syncrepl_updateCookie: rid=7 be_modify failed (50) request done: ld 0x82c2228 msgid 1 syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5797e8c-0486-102c-83e0-79137da6179f dn_callback : entries have identical CSN dc=ossa,dc=linagora,dc=org ours 20071001162546.703481Z#000000#000#000000, new 20071001162546.703481Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (dc=ossa,dc=linagora,dc=org) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a2f834-0486-102c-83e1-79137da6179f dn_callback : entries have identical CSN uid=root,dc=ossa,dc=linagora,dc=org ours 20071001162546.975377Z#000000#000#000000, new 20071001162546.975377Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=root,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (uid=root,dc=ossa,dc=linagora,dc=org) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a31526-0486-102c-83e2-79137da6179f dn_callback : entries have identical CSN uid=replicator,dc=ossa,dc=linagora,dc=org ours 20071001162546.976133Z#000000#000#000000, new 20071001162546.976133Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=replicator,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (uid=replicator,dc=ossa,dc=linagora,dc=org) 8>--------------------------------------------------------------- Obviously, the desired result is that entries are not deleted from the BOTTOM server when replication happens. I'm a bit at a loss as to the logic behind these updates, and how to go about correcting. I tried applying a patch backported from HEAD to 2.3.38 that makes syncrepl update the contextCSN in the real root (not the bdb database root). It works in that the contextCSN is updated correctly, but replication to BOTTOM still has unwanted deletes. The patch is in the archive attached (update-root-contextCSN.diff) and corresponds to revisions 1.308 and 1.309 in syncrepl.c CVS log. I am completely available to provide any more information necessary: logs, testing, gdb output, etc. Any help or pointers most welcome! Thanks in advance, Jon

1 0

Re: (ITS#4467) snprintf is consistenly used wrongly
by ando＠sys-net.it 29 Sep '07

29 Sep '07

h.b.furuseth(a)usit.uio.no wrote: > OpenLDAP is full of code like > ptr += snprintf( ptr, ... ); > and > bv.bv_len = snprintf( ... ); > <use bv>; Let me add that there seem to be occasional improper uses of sprintf() too (usually in marginal code, fortunately). 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

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