openldap-bugs March 2009

openldap-bugs@openldap.org

48 participants
245 discussions

Start a nNew thread

Re: (ITS#6027) Debug() accesses free()-d memory in register_at() on error
by test.007＠seznam.cz 23 Mar '09

23 Mar '09

Verified. Thanks. Mr. Chu, you're right my build was broken.

1 0

Re: patch filed (ITS#5366)
by peter＠adpm.de 22 Mar '09

22 Mar '09

Hi, I filed a patch that should fix this ITS. It can be found at ftp://ftp.openldap.org/incoming/PeterMarschall-090322.patch and brings the man page in line with the code. Regards Peter -- Peter Marschall peter(a)adpm.de

1 0

Re: (ITS#6029) slapadd lockup
by quanah＠zimbra.com 21 Mar '09

21 Mar '09

After around 24 hours, backtrace is the same: (gdb) thr apply all bt Thread 5 (Thread 1106889024 (LWP 9361)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1124 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1115281728 (LWP 9362)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1123674432 (LWP 9363)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1132067136 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 Thread 1 (Thread 47794824997056 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 --On Sunday, March 22, 2009 2:37 AM +0000 quanah(a)zimbra.com wrote: > --On Saturday, March 21, 2009 7:09 PM -0700 Howard Chu <hyc(a)symas.com> > wrote: > >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: RE24 3/19/2009 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.29.239) >>> >>> >>> While testing various load scenarios, slapadd deadlocked on me. >> >> The trace for thread 1 and 2 look identical, so I'm assuming they're the >> same thread. In that case I see 3 tool threads running. How many did you >> have configured? If 1 and 2 are really different threads (certainly their >> thread IDs look quite different), then there's something very wrong in >> the thread library... >> >> print bdb_tool_index_tcount >> > > (gdb) print bdb_tool_index_tcount > $1 = 1 > > >> It looks like one thread has exited early. I'm not sure how that can >> happen since the only way for any index thread to exit is if >> slapd_shutdown is set. Is it set? > > (gdb) print slapd_shutdown > $2 = 0 > > > It's configured with 4 tool threads. > > --Quanah > >>> (gdb) thr apply all bt >>> >>> Thread 5 (Thread 1106889024 (LWP 9361)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized >>> # out>, >>> ptr=<value optimized out>) at tools.c:1124 >>> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >>> # (xpool=0x17e07fd0) at >>> ../../../libraries/libldap_r/tpool.c:663 >>> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >>> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >>> >>> Thread 4 (Thread 1115281728 (LWP 9362)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >>> # out>, >>> ptr=<value optimized out>) at tools.c:1147 >>> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >>> # (xpool=0x17e07fd0) at >>> ../../../libraries/libldap_r/tpool.c:663 >>> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >>> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >>> >>> Thread 3 (Thread 1123674432 (LWP 9363)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >>> # out>, >>> ptr=<value optimized out>) at tools.c:1147 >>> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >>> # (xpool=0x17e07fd0) at >>> ../../../libraries/libldap_r/tpool.c:663 >>> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >>> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >>> >>> Thread 2 (Thread 1132067136 (LWP 9360)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >>> # txn=<value >>> optimized out>, e=0x2b7b521d2068) at tools.c:475 >>> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >>> # e=0x2b7b521d2068, >>> text=0x7fff93960cc0) at tools.c:545 >>> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >>> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >>> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >>> ../../../servers/slapd/main.c:391 >>> >>> Thread 1 (Thread 47794824997056 (LWP 9360)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >>> # txn=<value >>> optimized out>, e=0x2b7b521d2068) at tools.c:475 >>> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >>> # e=0x2b7b521d2068, >>> text=0x7fff93960cc0) at tools.c:545 >>> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >>> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >>> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >>> ../../../servers/slapd/main.c:391 >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6029) slapadd lockup
by quanah＠zimbra.com 21 Mar '09

21 Mar '09

--On Saturday, March 21, 2009 7:09 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: RE24 3/19/2009 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> While testing various load scenarios, slapadd deadlocked on me. > > The trace for thread 1 and 2 look identical, so I'm assuming they're the > same thread. In that case I see 3 tool threads running. How many did you > have configured? If 1 and 2 are really different threads (certainly their > thread IDs look quite different), then there's something very wrong in > the thread library... > > print bdb_tool_index_tcount > (gdb) print bdb_tool_index_tcount $1 = 1 > It looks like one thread has exited early. I'm not sure how that can > happen since the only way for any index thread to exit is if > slapd_shutdown is set. Is it set? (gdb) print slapd_shutdown $2 = 0 It's configured with 4 tool threads. --Quanah >> (gdb) thr apply all bt >> >> Thread 5 (Thread 1106889024 (LWP 9361)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1124 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 4 (Thread 1115281728 (LWP 9362)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1147 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 3 (Thread 1123674432 (LWP 9363)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1147 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 2 (Thread 1132067136 (LWP 9360)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >> # txn=<value >> optimized out>, e=0x2b7b521d2068) at tools.c:475 >> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >> # e=0x2b7b521d2068, >> text=0x7fff93960cc0) at tools.c:545 >> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >> ../../../servers/slapd/main.c:391 >> >> Thread 1 (Thread 47794824997056 (LWP 9360)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >> # txn=<value >> optimized out>, e=0x2b7b521d2068) at tools.c:475 >> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >> # e=0x2b7b521d2068, >> text=0x7fff93960cc0) at tools.c:545 >> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >> ../../../servers/slapd/main.c:391 >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6029) slapadd lockup
by hyc＠symas.com 21 Mar '09

21 Mar '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 3/19/2009 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > While testing various load scenarios, slapadd deadlocked on me. The trace for thread 1 and 2 look identical, so I'm assuming they're the same thread. In that case I see 3 tool threads running. How many did you have configured? If 1 and 2 are really different threads (certainly their thread IDs look quite different), then there's something very wrong in the thread library... print bdb_tool_index_tcount It looks like one thread has exited early. I'm not sure how that can happen since the only way for any index thread to exit is if slapd_shutdown is set. Is it set? > > (gdb) thr apply all bt > > Thread 5 (Thread 1106889024 (LWP 9361)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1124 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 4 (Thread 1115281728 (LWP 9362)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1147 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 3 (Thread 1123674432 (LWP 9363)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1147 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 2 (Thread 1132067136 (LWP 9360)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value > optimized out>, e=0x2b7b521d2068) at tools.c:475 > #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, > text=0x7fff93960cc0) at tools.c:545 > #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, > argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 > #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at > ../../../servers/slapd/main.c:391 > > Thread 1 (Thread 47794824997056 (LWP 9360)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value > optimized out>, e=0x2b7b521d2068) at tools.c:475 > #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, > text=0x7fff93960cc0) at tools.c:545 > #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, > argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 > #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at > ../../../servers/slapd/main.c:391 > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 -- -- 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#6029) slapadd lockup
by quanah＠zimbra.com 21 Mar '09

21 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24 3/19/2009 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) While testing various load scenarios, slapadd deadlocked on me. (gdb) thr apply all bt Thread 5 (Thread 1106889024 (LWP 9361)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1124 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1115281728 (LWP 9362)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1123674432 (LWP 9363)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1132067136 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 Thread 1 (Thread 47794824997056 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

1 0

Re: Fw: Re: (ITS#5988) entries skipped in n-way mutimaster replication
by rein＠OpenLDAP.org 20 Mar '09

20 Mar '09

adrien.futschik(a)atosorigin.com wrote: >> Some changes have been made in the syncprov overlay's queue management in >> CVS HEAD. The test050 script has also been changed to test up to 9 masters, >> and it passes for me with several hundred iterations of 9 servers. (Some of >> the timing delays have to be increased though.) >> > I have tested the HEAD version of OpenLDAP (10/03/09 - 14:48) and I still have > problems with some entries not being added. There are important bugfixes committed after 10/03/09, including fixes to this ITS. As of now you should test the RE24 branch, which is being prepared for an upcoming 2.4.16 release. Rein

1 0

Re: Fw: Re: (ITS#5988) entries skipped in n-way mutimaster replication
by adrien.futschik＠atosorigin.com 20 Mar '09

20 Mar '09

--Boundary-00=_8B4wJH+c2cGJw4l Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Some changes have been made in the syncprov overlay's queue management in > CVS HEAD. The test050 script has also been changed to test up to 9 masters, > and it passes for me with several hundred iterations of 9 servers. (Some of > the timing delays have to be increased though.) > I have tested the HEAD version of OpenLDAP (10/03/09 - 14:48) and I still have problems with some entries not being added. I did not change my configuration. Here is an example of what I see in the log files : on M2 (where the entry is added) : [...] conn=32 fd=28 ACCEPT from IP=163.106.38.124:49986 (IP=163.106.38.92:9012) conn=32 op=0 BIND dn="cn=admin,c=fr" method=128 conn=32 op=0 BIND dn="cn=admin,c=fr" mech=SIMPLE ssf=0 conn=32 op=0 RESULT tag=97 err=0 text= conn=32 op=1 ADD dn="cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr" slap_queue_csn: queing 0x41000360 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 conn=32 op=1 RESULT tag=105 err=0 text= slap_graduate_commit_csn: removing 0x2aaab00457e0 20090320101016.082209Z#000000#002#000000 conn=32 op=2 UNBIND conn=32 fd=28 closed [...] on M1 : [...] do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=001,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] do_syncrep2: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] on M3 : [...] do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x1b35e3d0 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x1b35d660 20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 be_add (0) do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=003,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] on M4 : [...] do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 dn_callback : entries have identical CSN cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.075365Z#000000#001#000000 slap_queue_csn: queing 0x38c1610 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr) slap_graduate_commit_csn: removing 0x38bdce0 20090320101016.075365Z#000000#001#000000 slap_graduate_commit_csn: removing 0x38c20d0 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad0008c70 20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x2aaad0009ff0 20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac40234b0 20090320101016.118097Z#000000#001#000000 slap_queue_csn: queing 0x2aaad00032c0 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=012 be_add (0) slap_graduate_commit_csn: removing 0x2aaac40270f0 20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad000b770 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.162183Z#000000#001#000000 slap_queue_csn: queing 0x2aaad000a710 20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaac4027050 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) slap_graduate_commit_csn: removing 0x2aaad0009fb0 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad000a660 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.205384Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad0008a50 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 be_add (0) slap_graduate_commit_csn: removing 0x2aaac4027960 20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (68) dn_callback : entries have identical CSN cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 entry unchanged, ignored (cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=013 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] Do you have any idea what's going on ? I hoppe this will help Adrien Futschik --Boundary-00=_8B4wJH+c2cGJw4l Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'Sans Serif'; font-size:8pt; font-weight:400; font-style:normal;">> Some changes have been made in the syncprov overlay's queue management in > CVS HEAD. The test050 script has also been changed to test up to 9 masters, > and it passes for me with several hundred iterations of 9 servers. (Some of > the timing delays have to be increased though.) > I have tested the HEAD version of OpenLDAP (10/03/09 - 14:48) and I still have problems with some entries not being added. I did not change my configuration. Here is an example of what I see in the log files : on M2 (where the entry is added) : [...] conn=32 fd=28 ACCEPT from IP=163.106.38.124:49986 (IP=163.106.38.92:9012) conn=32 op=0 BIND dn="cn=admin,c=fr" method=128 conn=32 op=0 BIND dn="cn=admin,c=fr" mech=SIMPLE ssf=0 conn=32 op=0 RESULT tag=97 err=0 text= conn=32 op=1 ADD dn="cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr" slap_queue_csn: queing 0x41000360 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 conn=32 op=1 RESULT tag=105 err=0 text= slap_graduate_commit_csn: removing 0x2aaab00457e0 20090320101016.082209Z#000000#002#000000 conn=32 op=2 UNBIND conn=32 fd=28 closed [...] on M1 : [...] do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=001,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] do_syncrep2: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] on M3 : [...] do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x1b35e3d0 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x1b35d660 20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 be_add (0) do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=003,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] on M4 : [...] do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 dn_callback : entries have identical CSN cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.075365Z#000000#001#000000 slap_queue_csn: queing 0x38c1610 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr) slap_graduate_commit_csn: removing 0x38bdce0 20090320101016.075365Z#000000#001#000000 slap_graduate_commit_csn: removing 0x38c20d0 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad0008c70 20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x2aaad0009ff0 20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac40234b0 20090320101016.118097Z#000000#001#000000 slap_queue_csn: queing 0x2aaad00032c0 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=012 be_add (0) slap_graduate_commit_csn: removing 0x2aaac40270f0 20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad000b770 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.162183Z#000000#001#000000 slap_queue_csn: queing 0x2aaad000a710 20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaac4027050 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) slap_graduate_commit_csn: removing 0x2aaad0009fb0 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad000a660 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.205384Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad0008a50 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 be_add (0) slap_graduate_commit_csn: removing 0x2aaac4027960 20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (68) dn_callback : entries have identical CSN cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 entry unchanged, ignored (cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=013 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] Do you have any idea what's going on ? I hoppe this will help Adrien Futschik</body></html> --Boundary-00=_8B4wJH+c2cGJw4l--

1 0

Re: (ITS#4941) incorrect description of TLS_REQCERT setting
by hyc＠symas.com 19 Mar '09

19 Mar '09

Howard Chu wrote: > Philip Guenther wrote: >> On Mon, 30 Apr 2007, Howard Chu wrote: >>> guenther+ldapdev(a)sendmail.com wrote: >> ... >>>> - 'allow' checks the identity of the server vs its cert (per RFC 4513, >>>> section 3.1.3) and will terminate the connection if they don't match >>>> - 'try' is the same as 'demand' and 'hard' >>> Not quite. With both "allow" and "try" it's OK if the server provides no >>> certificate. >> >> That's true of 'demand' and 'hard' as well. The only difference between >> 'try' and 'demand' in the code is that the latter passes >> SSL_CTX_set_verify() the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, but that >> flag has NO EFFECT on SSL clients. This is documented on the >> SSL_CTX_set_verify() manpage and confirmed by grepping the openssl source >> for it. >> >> If you don't believe me, I suggest you try configuring your server to >> accept the ADH suites (don't forget to set TLSDHParamFile to /dev/null) >> and give ldapsearch a whirl with >> LDAPTLS_REQCERT=hard >> LDAPTLS_CIPHER_SUITE=ADH-AES256-SHA >> >> in your environment. That's what I did. > > When this text was written, there was no support for anonymous cipher suites. > So the meaning of the text is: assuming a cipher suite that actually uses > certificates, the client would proceed even if the server didn't provide a > cert. It's entirely possible that this circumstance has been overcome by other > developments. Most likely this hasn't been a valid use case for quite a long > time. But it has nothing to do with Diffie-Hellman key exchanges... Aside from clarifying that we're assuming the use of X.509 certificates in the first place, this text is correct. I note that GnuTLS also works with OpenPGP keys, but I've never tested that here. Anyway, the current description is also accurate for GnuTLS. -- -- 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: add option for setting minimum TLS/SSL protocol (ITS#5655)
by guenther＠sendmail.com 19 Mar '09

19 Mar '09

On Fri, 23 Jan 2009, Howard Chu wrote: > guenther(a)sendmail.com wrote: > > I could have sworn I had uploaded the revised version of the patch back in > > August after some cleaning by Kurt, but have no way of confirming it. So > > I've uploaded it again as guenther-20081204.patch. > > Thanks, patch looks good, committed to HEAD. Have you got a manpage > update, by the way? Here's the chunk for ldap.conf(5), diffed against the trunk. None of the LDAP_OPT_X_TLS* options appear to be documented, so I didn't add anything to ldap_get_option(3). Philip Index: doc/man/man5/ldap.conf.5 =================================================================== RCS file: /data/cvs/openldap/pkg/ldap/doc/man/man5/ldap.conf.5,v retrieving revision 1.50 diff -u -r1.50 ldap.conf.5 --- doc/man/man5/ldap.conf.5 26 Jan 2009 01:54:32 -0000 1.50 +++ doc/man/man5/ldap.conf.5 19 Mar 2009 18:22:00 -0000 @@ -336,6 +336,19 @@ gnutls-cli -l .fi .TP +.B TLS_PROTOCOL_MIN <major>[.<minor>] +Specifies minimum SSL protocol version that will be negoiated. +If the server doesn't support at least that version, +the SSL handshake will fail. +To require TLS 1.x or higher, set this option to 3.(x+1), +e.g., +.B TLS_PROTOCOL_MIN 3.2 +would require TLS 1.1. +Specifying a minimum that is higher than that supported by the +OpenLDAP implementation will result it in requiring the +highest level that it does support. +This parameter is currently ignored with GNUtls. +.TP .B TLS_RANDFILE <filename> Specifies the file to obtain random bits from when /dev/[u]random is not available. Generally set to the name of the EGD/PRNGD socket.

1 0

← Newer
1
2
3
4
5
6
7
8
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2009