openldap-bugs September 2012

openldap-bugs@openldap.org

29 participants
107 discussions

Re: (ITS#7382) slapadd segfaults (during freeing resources)
by hyc＠symas.com 09 Sep '12

09 Sep '12

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: OPENLDAP_REL_ENG > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:9feb:ff02:2958:c83c:2589:166d) > > > Hi, Looks like you're mixing different libldaps in the same process. libldap init.c:484 is not what your backtrace shows. At least, not in the RE24 branch. Closing this ITS, your environment is invalid. > root@srv:/home/tester/src/openldap# gdb > /home/tester/src/openldap/servers/slapd/slapadd > GNU gdb (GDB) 7.4.1-debian > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /home/tester/src/openldap/servers/slapd/slapadd...done. > (gdb) run -v -F /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l > /tmp/example_data.ldif > Starting program: /home/tester/src/openldap/servers/slapd/slapadd -v -F > /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l /tmp/example_data.ldif > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > 504cc479 mdb_id2entry_put: mdb_put failed: MDB_KEYEXIST: Key/data pair already > exists(-30799) "dc=example,dc=com" > 504cc479 => mdb_tool_entry_put: id2entry_add failed: err=-30799 > 504cc479 => mdb_tool_entry_put: txn_aborted! MDB_KEYEXIST: Key/data pair already > exists (-30799) > slapadd: could not add entry dn="dc=example,dc=com" (line=1): txn_aborted! > MDB_KEYEXIST: Key/data pair already exists (-30799) > _### 16.13% eta none elapsed none spd 501.5 k/s > Closing DB... > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) bt full > #0 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 > No symbol table info available. > #1 0x0000000000592f46 in ber_memfree_x (p=0x426f6f462f6d6f74, ctx=0x0) at > memory.c:152 > __PRETTY_FUNCTION__ = "ber_memfree_x" > #2 0x0000000000579f5f in ldap_free_urldesc (ludp=0x8fcd10) at url.c:1528 > No locals. > #3 0x0000000000579f15 in ldap_free_urllist (ludlist=0x8fcd10) at url.c:1516 > ludp = 0x8fcd10 > next = 0x7375632f6374652f > #4 0x00007ffff635b2b3 in ldap_int_destroy_global_options () at init.c:484 > gopts = 0x7ffff6599080 > #5 0x00007ffff7defef9 in ?? () from /lib64/ld-linux-x86-64.so.2 > No symbol table info available. > #6 0x00007ffff7df09ce in ?? () from /lib64/ld-linux-x86-64.so.2 > No symbol table info available. > #7 0x00007ffff7deabd6 in ?? () from /lib64/ld-linux-x86-64.so.2 > No symbol table info available. > #8 0x00007ffff79d12ec in ?? () from /lib/x86_64-linux-gnu/libdl.so.2 > No symbol table info available. > #9 0x00007ffff79d100f in dlclose () from /lib/x86_64-linux-gnu/libdl.so.2 > No symbol table info available. > #10 0x00007ffff77c8291 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 > No symbol table info available. > #11 0x00007ffff77bfae1 in sasl_common_done () from > /usr/lib/x86_64-linux-gnu/libsasl2.so.2 > No symbol table info available. > #12 0x00000000004b34d4 in slap_sasl_destroy () at sasl.c:1190 > No locals. > #13 0x0000000000482039 in slap_destroy () at init.c:249 > rc = 0 > #14 0x00000000004ddbc8 in slap_tool_destroy () at slapcommon.c:932 > rc = 0 > #15 0x00000000004db86f in slapadd (argc=8, argv=0x7fffffffe648) at > slapadd.c:502 > textbuf = "\000xn_aborted! MDB_KEYEXIST: Key/data pair already exists > (-30799)", '\000' <repeats 191 times> > textlen = 256 > erec = {e = 0x8db288, lineno = 1, nextline = 14} > bvtext = {bv_len = 256, bv_val = 0x7fffffffe300 ""} > thr = 4270934 > id = 18446744073709551615 > prev = 0x0 > ldifrc = 1 > rc = 1 > stat_buf = {st_dev = 2307, st_ino = 149868, st_nlink = 1, st_mode = > 33188, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 2225, > st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1347128272, > tv_nsec = 0}, st_mtim = {tv_sec = 1347128189, tv_nsec = 0}, st_ctim = { > tv_sec = 1347128189, tv_nsec = 0}, __unused = {0, 0, 0}} > #16 0x000000000041e688 in main (argc=8, argv=0x7fffffffe648) at main.c:410 > i = 0 > no_detach = 0 > ---Type <return> to continue, or q <return> to quit--- > rc = 1 > urls = 0x0 > username = 0x0 > groupname = 0x0 > sandbox = 0x0 > syslogUser = 160 > pid = 32767 > waitfds = {0, 0} > g_argc = 8 > g_argv = 0x7fffffffe648 > configfile = 0x0 > configdir = 0x0 > serverName = 0x7fffffffe8c3 "slapadd" > serverMode = 1 > scp = 0x0 > scp_entry = 0x0 > debug_unknowns = 0x0 > syslog_unknowns = 0x0 > serverNamePrefix = 0x596388 "" > l = 140733193388033 > slapd_pid_file_unlink = 0 > slapd_args_file_unlink = 0 > firstopt = 1 > __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#7382) slapadd segfaults (during freeing resources)
by daniel＠pluta.biz 09 Sep '12

09 Sep '12

Full_Name: Daniel Pluta Version: OPENLDAP_REL_ENG OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:2958:c83c:2589:166d) Hi, root@srv:/home/tester/src/openldap# gdb /home/tester/src/openldap/servers/slapd/slapadd GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/tester/src/openldap/servers/slapd/slapadd...done. (gdb) run -v -F /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l /tmp/example_data.ldif Starting program: /home/tester/src/openldap/servers/slapd/slapadd -v -F /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l /tmp/example_data.ldif [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 504cc479 mdb_id2entry_put: mdb_put failed: MDB_KEYEXIST: Key/data pair already exists(-30799) "dc=example,dc=com" 504cc479 => mdb_tool_entry_put: id2entry_add failed: err=-30799 504cc479 => mdb_tool_entry_put: txn_aborted! MDB_KEYEXIST: Key/data pair already exists (-30799) slapadd: could not add entry dn="dc=example,dc=com" (line=1): txn_aborted! MDB_KEYEXIST: Key/data pair already exists (-30799) _### 16.13% eta none elapsed none spd 501.5 k/s Closing DB... Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt full #0 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x0000000000592f46 in ber_memfree_x (p=0x426f6f462f6d6f74, ctx=0x0) at memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #2 0x0000000000579f5f in ldap_free_urldesc (ludp=0x8fcd10) at url.c:1528 No locals. #3 0x0000000000579f15 in ldap_free_urllist (ludlist=0x8fcd10) at url.c:1516 ludp = 0x8fcd10 next = 0x7375632f6374652f #4 0x00007ffff635b2b3 in ldap_int_destroy_global_options () at init.c:484 gopts = 0x7ffff6599080 #5 0x00007ffff7defef9 in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #6 0x00007ffff7df09ce in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #7 0x00007ffff7deabd6 in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #8 0x00007ffff79d12ec in ?? () from /lib/x86_64-linux-gnu/libdl.so.2 No symbol table info available. #9 0x00007ffff79d100f in dlclose () from /lib/x86_64-linux-gnu/libdl.so.2 No symbol table info available. #10 0x00007ffff77c8291 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 No symbol table info available. #11 0x00007ffff77bfae1 in sasl_common_done () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 No symbol table info available. #12 0x00000000004b34d4 in slap_sasl_destroy () at sasl.c:1190 No locals. #13 0x0000000000482039 in slap_destroy () at init.c:249 rc = 0 #14 0x00000000004ddbc8 in slap_tool_destroy () at slapcommon.c:932 rc = 0 #15 0x00000000004db86f in slapadd (argc=8, argv=0x7fffffffe648) at slapadd.c:502 textbuf = "\000xn_aborted! MDB_KEYEXIST: Key/data pair already exists (-30799)", '\000' <repeats 191 times> textlen = 256 erec = {e = 0x8db288, lineno = 1, nextline = 14} bvtext = {bv_len = 256, bv_val = 0x7fffffffe300 ""} thr = 4270934 id = 18446744073709551615 prev = 0x0 ldifrc = 1 rc = 1 stat_buf = {st_dev = 2307, st_ino = 149868, st_nlink = 1, st_mode = 33188, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 2225, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1347128272, tv_nsec = 0}, st_mtim = {tv_sec = 1347128189, tv_nsec = 0}, st_ctim = { tv_sec = 1347128189, tv_nsec = 0}, __unused = {0, 0, 0}} #16 0x000000000041e688 in main (argc=8, argv=0x7fffffffe648) at main.c:410 i = 0 no_detach = 0 ---Type <return> to continue, or q <return> to quit--- rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 32767 waitfds = {0, 0} g_argc = 8 g_argv = 0x7fffffffe648 configfile = 0x0 configdir = 0x0 serverName = 0x7fffffffe8c3 "slapadd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x596388 "" l = 140733193388033 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by h.b.furuseth＠usit.uio.no 06 Sep '12

06 Sep '12

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> This is worse with a database with is intended to be used by >> different users (A and B): > (...) >> mdb_env_setup_locks() can sem_unlink both semaphores before doing >> anything else, so that reopening a database as root will clean up. >> Drop the error checks of sem_unlink (so both get called), instead >> use O_EXCL in sem_open(,O_CREAT,,). Unless I'm missing something, >> the error checks just work like an emulation of O_EXCL anyway. > > The sem_unlink() and sem_open() sequence isn't ideal, certainly. I would > prefer to just use the existing semaphore. I just realized reusing the semaphores is a security problem: Anyone who can compute/read the semaphore names, can create the semaphores owned by themselves and then muck with them to sabotage someone else's mdb. I suppose the same goes for SysV semaphores. I don't know what the accepted way to deal with that is, but I suggest to unlink + O_EXCL as above for now, document the multi-uid restriction, and punt the rest until anyone who cares shows up. > Another possibility is to just use SysV semaphores instead of POSIX > semaphores. Then you can use the ipcs(1) command to manually cleanup. > (...) [later] > I'm also reminded that there is no defined behavior for SysV > semaphores in threads, they are only speciried for inter-process > synchronization. So forget that... I expect the work-around is to use them for IPC only, and wrap them in process-local mutexes in the MDB_env for thread sync. -- Hallvard

1 0

(ITS#7381) Dynamically added chaining configuration stops working after restart
by ian＠uns.ac.rs 05 Sep '12

05 Sep '12

Full_Name: Ivan Nejgebauer Version: 2.4.32 OS: CentOS 5 URL: ftp://ftp.openldap.org/incoming/ivannejgebauer-120905.tgz Submission from: (NULL) (2001:4170:2000:2:213:d3ff:fecf:b9ea) If a minimal chaining configuration is dynamically added to a consumer server in a provider/consumer pair running delta-syncrepl, it will stop working when the consumer is restarted. The configuration is modelled after the one used in test022 in the OpenLDAP source distribution: dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbIDAssertBind: bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials="secret" mode=self olcDbURI: "ldap://localhost:6389" Scripts and data for replicating the issue are in the referenced archive. Quick summary: # make clean-all master replica # ./start-master.sh # ./start-replica.sh # ./replica-apply.sh pmod-add.ldif # returns referral # ./replica-conf.sh chain.ldif # adds chaining configuration # ./replica-apply.sh pmod-add.ldif # chains to master # ./stop-replica.sh # ./start-replica.sh # ./replica-apply.sh pmod-del.ldif # returns referral, but shouldn't I have tested both 2.4.32 and git master (54a111907b48900e1ce5de12a9d87818a334423d).

1 0

(ITS#7380) Open LDAP and Oracle Backend
by iliyas.nadaf＠gmail.com 04 Sep '12

04 Sep '12

Full_Name: iliyas Version: openldap-2.4.31 OS: solaris-x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.160.74.254) Hi, I need to develope "ladap client in C" with OpenLdap source and backend as Oracle database 11gr2. If it is possible suggest some resources. I have done it properly with BDB. Thanks, Iliyas

1 0

(ITS#7379) Open LDAP and Oracle Backend
by iliyas.nadaf＠gmail.com 04 Sep '12

04 Sep '12

1 0

Re: (ITS#7378) Slapd hangs on bdb write lock
by nikolai＠net24.co.nz 04 Sep '12

04 Sep '12

Thanks guys - I think we will look at going to MDB as well now. On 4/09/2012, at 8:42 AM, Quanah Gibson-Mount wrote: > --On Monday, September 03, 2012 6:35 PM +0000 hyc(a)symas.com wrote: > >> Nikolai Schupbach wrote: >>> Hi Howard, >>> >>> Thank you very much for the explanation. What BDB version would you >> recommend. Obviously I have quite a few options and would like to use a >> version that is known to be very solid. >> >> I believe 4.7.25 + all 4 of its official patches was pretty stable. >> http://www.oracle.com/technetwork/products/berkeleydb/patch-088170.html >> >> I've done limited testing with 4.8.30, 5.1.19, and 5.3.21. At this point >> I'm no longer tracking BDB revisions since MDB has superior performance >> while using 1/4 as much RAM and requiring no tuning. > > We've been using BDB 4.7.25+all 4 patches without issue for several years as well. However, I will also note that we are now switching over to MDB as well for our production services starting with OpenLDAP 2.4.32. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7378) Slapd hangs on bdb write lock
by quanah＠zimbra.com 03 Sep '12

03 Sep '12

--On Monday, September 03, 2012 6:35 PM +0000 hyc(a)symas.com wrote: > Nikolai Schupbach wrote: >> Hi Howard, >> >> Thank you very much for the explanation. What BDB version would you > recommend. Obviously I have quite a few options and would like to use a > version that is known to be very solid. > > I believe 4.7.25 + all 4 of its official patches was pretty stable. > http://www.oracle.com/technetwork/products/berkeleydb/patch-088170.html > > I've done limited testing with 4.8.30, 5.1.19, and 5.3.21. At this point > I'm no longer tracking BDB revisions since MDB has superior performance > while using 1/4 as much RAM and requiring no tuning. We've been using BDB 4.7.25+all 4 patches without issue for several years as well. However, I will also note that we are now switching over to MDB as well for our production services starting with OpenLDAP 2.4.32. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7378) Slapd hangs on bdb write lock
by hyc＠symas.com 03 Sep '12

03 Sep '12

Nikolai Schupbach wrote: > Hi Howard, > > Thank you very much for the explanation. What BDB version would you recommend. Obviously I have quite a few options and would like to use a version that is known to be very solid. I believe 4.7.25 + all 4 of its official patches was pretty stable. http://www.oracle.com/technetwork/products/berkeleydb/patch-088170.html I've done limited testing with 4.8.30, 5.1.19, and 5.3.21. At this point I'm no longer tracking BDB revisions since MDB has superior performance while using 1/4 as much RAM and requiring no tuning. > Sincerely, > Nikolai Schupbach > > On 3/09/2012, at 9:45 PM, Howard Chu wrote: > >> nikolai(a)net24.co.nz wrote: >>> Full_Name: Nikolai Schupbach >>> Version: 2.4.31 >>> OS: FreeBSD >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (202.78.158.60) >>> >>> >>> We are experiencing frequent hangs in slapd. Once hung we can continue to >>> connect, but all searches will just hang indefinitely until we kill -9 the slapd >>> process and restart it. The directory is used for mail routing and we have been >>> migrating to it from an existing directory server over the last 3 weeks - we >>> have noted the busier the directory becomes the more often it hangs (now once >>> every 2 days). >>> >>> We have one master and 10 syncrepl read only replicas - the master is used >>> mainly for writes and has not hung yet, but most of the replicas have hung at >>> least once. The replicas receive anywhere between 50 to 300 searches/sec, while >>> the master would only get 1/sec. There are 45k entries in the directory. >>> >>> We are running: >>> >>> FreeBSD 8.3/9.0 x64 >>> OpenLDAP 2.4.31 >>> Berkeley DB 4.6.21 >>> >>> The old directory we are migrating from has the same load and is also running >>> OpenLDAP, but has been rock solid for 5 years. It is running Berkeley DB 4.3.29 >>> and OpenLDAP 2.3.27. >>> >>> We have managed to collect db_stat lock information, which indicates the same >>> issue each time - a write lock on dn2id.bdb. >> >> It's more than that. Your db_stat shows that a single thread has 3 active >> transactions. This should never happen: >> >> 8000a85e dd= 0 locks held 2 write locks 0 pid/thread 88000/34386526336 >> 8000a85e READ 1 HELD 0xb19a8 len: 9 data: 40xa800000000000000 >> 8000a85e READ 1 HELD 0xb26c8 len: 9 data: 60xa800000000000000 >> 8000a85f dd= 0 locks held 8 write locks 4 pid/thread 88000/34386526336 >> 8000a85f READ 1 WAIT dn2id.bdb page 559 >> 8000a85f READ 1 HELD dn2id.bdb page 768 >> 8000a85f WRITE 2 HELD dn2id.bdb page 1362 >> 8000a85f READ 2 HELD dn2id.bdb page 1362 >> 8000a85f WRITE 2 HELD dn2id.bdb page 1353 >> 8000a85f READ 2 HELD dn2id.bdb page 1353 >> 8000a85f WRITE 2 HELD dn2id.bdb page 933 >> 8000a85f READ 1 HELD dn2id.bdb page 933 >> 8000a85f WRITE 4 HELD dn2id.bdb page 219 >> 80001047 dd=28 locks held 1 write locks 1 pid/thread 88000/34386526336 >> 80001047 WRITE 1 HELD dn2id.bdb page 559 >> >> I would first recommend changing from BDB 4.6.21 to some other version. There >> are no code paths in back-bdb where we would ever return without either >> committing or aborting the current transactions, so this appears to be a BDB >> bug, not an OpenLDAP bug. >> >>> We have also collected the backtrace for all the threads which I have uploaded >>> to: >>> >>> ftp://ftp.openldap.org/incoming/nikolai-gdb-120902.txt >>> >>> The full db_stat output is located at: >>> >>> ftp://ftp.openldap.org/incoming/nikolai-dbstat-120902.txt >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7378) Slapd hangs on bdb write lock
by nikolai＠net24.co.nz 03 Sep '12

03 Sep '12

Hi Howard, Thank you very much for the explanation. What BDB version would you recommend. Obviously I have quite a few options and would like to use a version that is known to be very solid. Sincerely, Nikolai Schupbach On 3/09/2012, at 9:45 PM, Howard Chu wrote: > nikolai(a)net24.co.nz wrote: >> Full_Name: Nikolai Schupbach >> Version: 2.4.31 >> OS: FreeBSD >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (202.78.158.60) >> >> >> We are experiencing frequent hangs in slapd. Once hung we can continue to >> connect, but all searches will just hang indefinitely until we kill -9 the slapd >> process and restart it. The directory is used for mail routing and we have been >> migrating to it from an existing directory server over the last 3 weeks - we >> have noted the busier the directory becomes the more often it hangs (now once >> every 2 days). >> >> We have one master and 10 syncrepl read only replicas - the master is used >> mainly for writes and has not hung yet, but most of the replicas have hung at >> least once. The replicas receive anywhere between 50 to 300 searches/sec, while >> the master would only get 1/sec. There are 45k entries in the directory. >> >> We are running: >> >> FreeBSD 8.3/9.0 x64 >> OpenLDAP 2.4.31 >> Berkeley DB 4.6.21 >> >> The old directory we are migrating from has the same load and is also running >> OpenLDAP, but has been rock solid for 5 years. It is running Berkeley DB 4.3.29 >> and OpenLDAP 2.3.27. >> >> We have managed to collect db_stat lock information, which indicates the same >> issue each time - a write lock on dn2id.bdb. > > It's more than that. Your db_stat shows that a single thread has 3 active > transactions. This should never happen: > > 8000a85e dd= 0 locks held 2 write locks 0 pid/thread 88000/34386526336 > 8000a85e READ 1 HELD 0xb19a8 len: 9 data: 40xa800000000000000 > 8000a85e READ 1 HELD 0xb26c8 len: 9 data: 60xa800000000000000 > 8000a85f dd= 0 locks held 8 write locks 4 pid/thread 88000/34386526336 > 8000a85f READ 1 WAIT dn2id.bdb page 559 > 8000a85f READ 1 HELD dn2id.bdb page 768 > 8000a85f WRITE 2 HELD dn2id.bdb page 1362 > 8000a85f READ 2 HELD dn2id.bdb page 1362 > 8000a85f WRITE 2 HELD dn2id.bdb page 1353 > 8000a85f READ 2 HELD dn2id.bdb page 1353 > 8000a85f WRITE 2 HELD dn2id.bdb page 933 > 8000a85f READ 1 HELD dn2id.bdb page 933 > 8000a85f WRITE 4 HELD dn2id.bdb page 219 > 80001047 dd=28 locks held 1 write locks 1 pid/thread 88000/34386526336 > 80001047 WRITE 1 HELD dn2id.bdb page 559 > > I would first recommend changing from BDB 4.6.21 to some other version. There > are no code paths in back-bdb where we would ever return without either > committing or aborting the current transactions, so this appears to be a BDB > bug, not an OpenLDAP bug. > >> We have also collected the backtrace for all the threads which I have uploaded >> to: >> >> ftp://ftp.openldap.org/incoming/nikolai-gdb-120902.txt >> >> The full db_stat output is located at: >> >> ftp://ftp.openldap.org/incoming/nikolai-dbstat-120902.txt > > -- > -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2012