openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6030) slapd segfaults when loading already present module
by hyc＠symas.com 23 Mar '09

23 Mar '09

HEAD has been changed to silently ignore these cases, please test. (I guess we could log something at LDAP_DEBUG_CONFIG level but that seems unnecessary at the moment.) luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: RE24/HEAD > OS: any > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > When loading a module through cn=config or slapd.conf moduleload directive, if > the module has already been loaded, slapd segfaults. Since it correctly finds > out the module is already registered shouldn't it refuse the modification when > the operation is attempted through cn=config or simply refuse to start when done > through slapd.conf? > > Last log lines (-d -1): > line 20 (moduleload syncprov.la) > loaded module syncprov.la > Control 1.3.6.1.4.1.4203.1.9.1.1 already registered. > syncprov_init: Failed to register control -9 > Segmentation fault > > backtrace: > #0 0x0000000b in ?? () > No symbol table info available. > #1 0x080dcb94 in module_load (file_name=0x89746bb "syncprov.la", argc=0, > argv=0x0) > at module.c:218 > module = (module_loaded_t *) 0x8976718 > error = 0x0 > rc = -9 > initialize = (MODULE_INIT_FN) 0x5f6936<init_module> > #2 0x0805bd1c in config_generic (c=0x8967970) at bconfig.c:1940 > i = 11784196 > __PRETTY_FUNCTION__ = "config_generic" > #3 0x0806a586 in config_set_vals (Conf=0x8168160, c=0x8967970) at config.c:314 > rc = 0 > arg_type = -2013265890 > ptr = (void *) 0x0 > #4 0x0806aa68 in config_add_vals (Conf=0x8168160, c=0x8967970) at config.c:383 > rc = 0 > arg_type = -2013265890 > #5 0x0806ba42 in read_config_file (fname=0x8932308 > "/usr/local/openldap/etc/slapd.conf", > depth=0, cf=0x0, cft=0x8167bc0) at config.c:736 > fp = (FILE *) 0x89692f8 > ct = (ConfigTable *) 0x8168160 > c = (ConfigArgs *) 0x8967970 > rc = 0 > s = {st_dev = 64768, __pad1 = 0, st_ino = 172196293, st_mode = 33152, > st_nlink = 1, > st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 1087, st_blksize = > 4096, > st_blocks = 8, st_atim = {tv_sec = 1237802811, tv_nsec = 0}, st_mtim = {tv_sec > = 1237802556, > tv_nsec = 0}, st_ctim = {tv_sec = 1237802556, tv_nsec = 0}, __unused4 = 0, > __unused5 = 0} > #6 0x08061626 in read_config (fname=0x8932308 > "/usr/local/openldap/etc/slapd.conf", dir=0x0) > at bconfig.c:3613 > be = (BackendDB *) 0x8967800 > cfb = (CfBackInfo *) 0x816c340 > cfdir = 0x11f0bc "" > cfname = 0x8932308 "/usr/local/openldap/etc/slapd.conf" > rc = 0 > __PRETTY_FUNCTION__ = "read_config" > #7 0x08057a5d in main (argc=5, argv=0xbfc1ce24) at main.c:754 > i = -1 > no_detach = 0 > rc = 0 > urls = 0x89323f0 "ldap://:9000" > username = 0x0 > groupname = 0x0 > sandbox = 0x0 > syslogUser = 160 > g_argc = 5 > g_argv = (char **) 0xbfc1ce24 > configfile = 0x8932308 "/usr/local/openldap/etc/slapd.conf" > configdir = 0x0 > serverName = 0xbfc1eb66 "slapd" > serverMode = 1 > scp = (struct sync_cookie *) 0x0 > scp_entry = (struct sync_cookie *) 0x0 > debug_unknowns = (char **) 0x0 > syslog_unknowns = (char **) 0x0 > serverNamePrefix = 0x811b537 "" > l = 1347407256 > slapd_pid_file_unlink = 0 > slapd_args_file_unlink = 0 > firstopt = 0 > __PRETTY_FUNCTION__ = "main" > > > -- -- 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#6030) slapd segfaults when loading already present module
by luca＠OpenLDAP.org 23 Mar '09

23 Mar '09

Full_Name: Luca Scamoni Version: RE24/HEAD OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) When loading a module through cn=config or slapd.conf moduleload directive, if the module has already been loaded, slapd segfaults. Since it correctly finds out the module is already registered shouldn't it refuse the modification when the operation is attempted through cn=config or simply refuse to start when done through slapd.conf? Last log lines (-d -1): line 20 (moduleload syncprov.la) loaded module syncprov.la Control 1.3.6.1.4.1.4203.1.9.1.1 already registered. syncprov_init: Failed to register control -9 Segmentation fault backtrace: #0 0x0000000b in ?? () No symbol table info available. #1 0x080dcb94 in module_load (file_name=0x89746bb "syncprov.la", argc=0, argv=0x0) at module.c:218 module = (module_loaded_t *) 0x8976718 error = 0x0 rc = -9 initialize = (MODULE_INIT_FN) 0x5f6936 <init_module> #2 0x0805bd1c in config_generic (c=0x8967970) at bconfig.c:1940 i = 11784196 __PRETTY_FUNCTION__ = "config_generic" #3 0x0806a586 in config_set_vals (Conf=0x8168160, c=0x8967970) at config.c:314 rc = 0 arg_type = -2013265890 ptr = (void *) 0x0 #4 0x0806aa68 in config_add_vals (Conf=0x8168160, c=0x8967970) at config.c:383 rc = 0 arg_type = -2013265890 #5 0x0806ba42 in read_config_file (fname=0x8932308 "/usr/local/openldap/etc/slapd.conf", depth=0, cf=0x0, cft=0x8167bc0) at config.c:736 fp = (FILE *) 0x89692f8 ct = (ConfigTable *) 0x8168160 c = (ConfigArgs *) 0x8967970 rc = 0 s = {st_dev = 64768, __pad1 = 0, st_ino = 172196293, st_mode = 33152, st_nlink = 1, st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 1087, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1237802811, tv_nsec = 0}, st_mtim = {tv_sec = 1237802556, tv_nsec = 0}, st_ctim = {tv_sec = 1237802556, tv_nsec = 0}, __unused4 = 0, __unused5 = 0} #6 0x08061626 in read_config (fname=0x8932308 "/usr/local/openldap/etc/slapd.conf", dir=0x0) at bconfig.c:3613 be = (BackendDB *) 0x8967800 cfb = (CfBackInfo *) 0x816c340 cfdir = 0x11f0bc "" cfname = 0x8932308 "/usr/local/openldap/etc/slapd.conf" rc = 0 __PRETTY_FUNCTION__ = "read_config" #7 0x08057a5d in main (argc=5, argv=0xbfc1ce24) at main.c:754 i = -1 no_detach = 0 rc = 0 urls = 0x89323f0 "ldap://:9000" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 5 g_argv = (char **) 0xbfc1ce24 configfile = 0x8932308 "/usr/local/openldap/etc/slapd.conf" configdir = 0x0 serverName = 0xbfc1eb66 "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x811b537 "" l = 1347407256 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 0 __PRETTY_FUNCTION__ = "main"

1 0

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

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