- openldap-bugs - openldap.org

Re: (ITS#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 08 Oct '07

08 Oct '07

> One more thing to check is just using "ls -l" to see if the actual size of > the log files corresponds with the db_stat offsets. E.g. if slave6 base1's > log.0000001 is really 8MB but the LSN is only 233KB, then we have to look for > a weird in-memory corruption. If not, then somebody reset your logs. No, it looks like those sizes all match. Actually, the "reset logs" may well be the case (although I still can't imagine how, I'm willing to just chalk this whole thing up to user error...of course logs show that the user was me, which is a shame :) and is hard to disprove (with only one log file active) with the exception of base2. base2 has multiple log files going back: [slave4] -rw------- 1 root root 9999986 Sep 6 18:03 log.0000000001 -rw------- 1 root root 9999967 Sep 10 14:03 log.0000000002 -rw------- 1 root root 9999983 Sep 18 16:33 log.0000000003 -rw------- 1 root root 9429761 Oct 8 05:33 log.0000000004 [slave6] -rw------- 1 root root 9999986 Sep 6 18:03 log.0000000001 -rw------- 1 root root 9999967 Sep 10 14:03 log.0000000002 -rw------- 1 root root 9999983 Sep 18 16:33 log.0000000003 -rw------- 1 root root 9429761 Oct 8 05:33 log.0000000004 which of course match the db_stat -l, but also extend back prior to September 24 according to the filesystem timestamps. I guess the argument could be made that log 4 was truncated on September 24...would that be detected/come up sane/come up bad in the db_stat?

1 0

(ITS#5177) refreshAndPersist race condition
by hyc＠OpenLDAP.org 08 Oct '07

08 Oct '07

Full_Name: Howard Chu Version: 2.3/2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc If heavy Add traffic is occurring while a refreshAndPersist consumer is refreshing, newly added entries may be omitted from the refresh phase without being queued into the Persist phase. reported by stelios.xx.grigoriadis(a)ericsson.com http://www.openldap.org/lists/openldap-bugs/200709/msg00172.html

1 0

Sync replication failure during startup.
by Stelios Grigoriadis 08 Oct '07

08 Oct '07

OpenLDAP v. 2.3.32 Berkeley DB 4.6 gcc 4.1.0 Replication doesn't work if the master server is started after the replica servers and a large amount of simoultaneous updates are performed while the server is starting up. The entries that didn't get replicated to the replicas will not be replicated even after a restart of both master and replicas. The contextCSN is set to a value larger than the entryCSN of the "lost" entries. This is what I think happens during a master server startup with simoultaneous updates ongoing (and replicas trying to sync in the initial phase). Suppose that two clients (Client1 and Client2) are adding the entries a and b respectively. If that happens between t1 and t2 (one second between) they will get the same entryCSN (same timestamp). If entry a is committed at tc1 and b at tc2, any replica search inbetween will only get the entry a. The entry b will be lost. Client1 entry=a, csn=x Client2 entry=b, csn=x Timeline ------+----------+---------+----+------> | | t1 | | t2=t1+1 | | tc1=entry a tc2=entry b committed committed Replica search query between tc1 and tc2. I don't know if a higher granularity would prevent this, or even better, to have some kind of a counter so that every modification gets a unique csn. Can you please comment on our analyzis to let us know if the analyzis is correct or if we have missed something important? Any help or hints on how to avoid or fix this problem is greatly appreciated. If I receive useful information direcly in private email, I will post a summary. Regards Stelios Grigoriadis

4 23

Re: (ITS#5171) hdb txn_checkpoint failures
by hyc＠symas.com 08 Oct '07

08 Oct '07

Aaron Richton wrote: >> It's still rather suspicious that slave4 and slave6 both had identical log >> status for base1 (1/188113) but different requested locations (1/8730339 vs >> 1/8730401). If they're identically configured slaves then they ought to be in >> lock-step. Then again, obviously they're not identical since slave6 doesn't >> show base4 in your log. > > Identical is relative. They've got the same OpenLDAP and supporting > binaries running on the same patches of Solaris 9 running identical > turn-up scripts with identical configuration files. But this is > production, so we've got data changes over time. For instance, the slaves > bootstrap with a slapadd -q, and the underlying slapcat could easily be > different from slave4 vs. slave6 (the most recent one is automatically > used). I'd imagine this would look different at the db layer, even once > syncrepl eventually converged the logical data? > >> Do you have the db_stat output from an uncorrupted slave? What about the >> master? > > Sure... https://www.nbcs.rutgers.edu/~richton/its5171_dbstatl2 Judging from the LSNs in use on these other servers, it sure looks like somebody went in and zeroed out your logs on slave4 and slave6. I don't think the environment spontaneously corrupted itself and reset the log offsets... One more thing to check is just using "ls -l" to see if the actual size of the log files corresponds with the db_stat offsets. E.g. if slave6 base1's log.0000001 is really 8MB but the LSN is only 233KB, then we have to look for a weird in-memory corruption. If not, then somebody reset your logs. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5176) Segmentation Fault in test001-slapadd
by openldap＠consotec.de 08 Oct '07

08 Oct '07

Full_Name: Mark Version: 2.3.38 OS: Suse Linux 10.01 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.128.87.178) ** Problem test001-slapdadd fails with segmentation fault. ** Environment Suse Linux 10.1 Berkly DB 4.6.21 Openldap 2.3.38 ** Configuration of ldap configure --prefix=/usr --enable-debug ** Shared Library depency libdb-4.6.so => /usr/lib/libdb-4.6.so (0x40028000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x40169000) libdl.so.2 => /lib/libdl.so.2 (0x40182000) libresolv.so.2 => /lib/libresolv.so.2 (0x40185000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40197000) libc.so.6 => /lib/i686/libc.so.6 (0x401e9000) ** StackTrace Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 32771 (LWP 28247)] 0x400bd3bd in __lock_get_internal (lt=0x8215ae8, sh_locker=0x7, flags=0, obj=0x82168d4, lock_mode=DB_LOCK_READ, timeout=0, lock=0x40d8e50c) at ../lock/lock.c:740 740 no_dd = sh_locker->master_locker == INVALID_ROFF && (gdb) bt #0 0x400bd3bd in __lock_get_internal (lt=0x8215ae8, sh_locker=0x7, flags=0, obj=0x82168d4, lock_mode=DB_LOCK_READ, timeout=0, lock=0x40d8e50c) at ../lock/lock.c:740 #1 0x400bcc85 in __lock_get (dbenv=0x82154e8, locker=0x7, flags=0, obj=0x82168d4, lock_mode=DB_LOCK_READ, lock=0x40d8e50c) at ../lock/lock.c:447 #2 0x400ec2f7 in __db_lget (dbc=0x8216858, action=0, pgno=1, mode=DB_LOCK_READ, lkflags=0, lockp=0x40d8e50c) at ../db/db_meta.c:1012 #3 0x40054d7d in __bam_get_root (dbc=0x8216858, pg=1, slevel=1, flags=1409, stack=0x40d8e614) at ../btree/bt_search.c:94 #4 0x400551a4 in __bam_search (dbc=0x8216858, root_pgno=1, key=0x40d8e97c, flags=1409, slevel=1, recnop=0x0, exactp=0x40d8e818) at ../btree/bt_search.c:200 #5 0x40045160 in __bamc_search (dbc=0x8216858, root_pgno=0, key=0x40d8e97c, flags=26, exactp=0x40d8e818) at ../btree/bt_cursor.c:2486 #6 0x400411bc in __bamc_get (dbc=0x8216858, key=0x40d8e97c, data=0x40d8e95c, flags=26, pgnop=0x40d8e8ac) at ../btree/bt_cursor.c:961 #7 0x400da81d in __dbc_get (dbc_arg=0x8217158, key=0x40d8e97c, data=0x40d8e95c, flags=26) at ../db/db_cam.c:697 #8 0x400e7dfb in __dbc_get_pp (dbc=0x8217158, key=0x40d8e97c, data=0x40d8e95c, flags=26) at ../db/db_iface.c:2022 #9 0x080d455f in bdb_id2entry (be=0x7, tid=0x0, locker=7, id=1, e=0x40d8e9f8) at id2entry.c:125 #10 0x080cdabb in bdb_cache_find_id (op=0x822a638, tid=0x0, id=1, eip=0x40d8ea84, islocked=0, locker=7, lock=0x40d8eb1c) at cache.c:760 #11 0x080d12cd in bdb_dn2entry (op=0x822a638, tid=0x0, dn=0x0, e=0x40d8eb14, matched=1, locker=7, lock=0x40d8eb1c) at dn2entry.c:68 #12 0x080b4ae9 in bdb_search (op=0x822a638, rs=0x40e4fc9c) at search.c:374 #13 0x0805ec5b in fe_op_search (op=0x822a638, rs=0x40e4fc9c) at search.c:355 #14 0x0805e43f in do_search (op=0x822a638, rs=0x40e4fc9c) at search.c:217 #15 0x0805cae2 in connection_operation (ctx=0x7, arg_v=0x822a638) at connection.c:1133 #16 0x080fd514 in ldap_int_thread_pool_wrapper (xpool=0x81c0a88) at tpool.c:478 #17 0x4019cf60 in pthread_start_thread () from /lib/i686/libpthread.so.0 #18 0x4019d0fe in pthread_start_thread_event () from /lib/i686/libpthread.so.0 #19 0x402c5327 in clone () from /lib/i686/libc.so.6 ** Description We added some printf's and found the that sh_locker has the value 0x7 which seems to be an index but not a valid lock for the database. Note: With the following modification the tests are running: File: servers/slapd/back-bdb/id2entry.c Line: 120 #if 0 /* Use our own locker if needed */ if ( !tid && locker ) cursor->locker = locker; #endif Any help is appriated Regards Mark

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 08 Oct '07

08 Oct '07

> It's still rather suspicious that slave4 and slave6 both had identical log > status for base1 (1/188113) but different requested locations (1/8730339 vs > 1/8730401). If they're identically configured slaves then they ought to be in > lock-step. Then again, obviously they're not identical since slave6 doesn't > show base4 in your log. Identical is relative. They've got the same OpenLDAP and supporting binaries running on the same patches of Solaris 9 running identical turn-up scripts with identical configuration files. But this is production, so we've got data changes over time. For instance, the slaves bootstrap with a slapadd -q, and the underlying slapcat could easily be different from slave4 vs. slave6 (the most recent one is automatically used). I'd imagine this would look different at the db layer, even once syncrepl eventually converged the logical data? > Do you have the db_stat output from an uncorrupted slave? What about the > master? Sure... https://www.nbcs.rutgers.edu/~richton/its5171_dbstatl2

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by hyc＠symas.com 08 Oct '07

08 Oct '07

Aaron Richton wrote: >> itself. Again, we can't really tell without single-stepping thru the BDB >> library code. It may not be worth the effort, but that's your call. > > The lock was > > env_region.c:290 MUTEX_LOCK(dbenv, &renv->mutex); > > but that wasn't making much sense....and after a couple minutes in dbx I > realized that I've been killing myself with the attempts at db_stat. > Yesterday's attempts were running db_* binaries with a wrong (but > compatible) ABI. It'd be nice if Sleepycat had some more/earlier checks > for that, but oh well... Kinda figured that that's what happened. > So anyway, I corrupted base2/slave4 by running the wrong db_stat, but that > left three other bases on slave4 and all three bases on slave6. I ran > db_stat -l on them, the output is: > > https://www.nbcs.rutgers.edu/~richton/its5171_dbstatl > BTW, this ABI screwup shouldn't be the root cause of the failures...I > haven't tried any db tools until the course of debugging this. These are > AUTOREMOVE, so db_archive is unlikely, for instance. It's still rather suspicious that slave4 and slave6 both had identical log status for base1 (1/188113) but different requested locations (1/8730339 vs 1/8730401). If they're identically configured slaves then they ought to be in lock-step. Then again, obviously they're not identical since slave6 doesn't show base4 in your log. Do you have the db_stat output from an uncorrupted slave? What about the master? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 08 Oct '07

08 Oct '07

> itself. Again, we can't really tell without single-stepping thru the BDB > library code. It may not be worth the effort, but that's your call. The lock was env_region.c:290 MUTEX_LOCK(dbenv, &renv->mutex); but that wasn't making much sense....and after a couple minutes in dbx I realized that I've been killing myself with the attempts at db_stat. Yesterday's attempts were running db_* binaries with a wrong (but compatible) ABI. It'd be nice if Sleepycat had some more/earlier checks for that, but oh well... So anyway, I corrupted base2/slave4 by running the wrong db_stat, but that left three other bases on slave4 and all three bases on slave6. I ran db_stat -l on them, the output is: https://www.nbcs.rutgers.edu/~richton/its5171_dbstatl BTW, this ABI screwup shouldn't be the root cause of the failures...I haven't tried any db tools until the course of debugging this. These are AUTOREMOVE, so db_archive is unlikely, for instance.

1 0

Re: (ITS#5050) array bounds violation in test045-syncreplication-proxied
by hyc＠symas.com 08 Oct '07

08 Oct '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE23 > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > syncprov + back-ldap, and presumably + back-meta if that were used, > give an array bounds violation in test045-syncreplication-proxied: > > syncprov_db_open() uses connection_fake_init(), which sets op->o_tag=0. > It passes op to back-ldap. > > ldap_back_op_result() assumes op is a known LDAP request: It calls > slap_req2op() and gets SLAP_OP_LAST (for unknown tag). That is used as > an index into ldapinfo_t.li_timeout[], which has size SLAP_OP_LAST. > > back-meta/bind.c does the same in meta_back_bind_op_result() and > meta_back_op_result(). I fixed back-ldap but I believe the same fix is still needed in back-meta. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5175) After 6 times authenticate sucessfully.Open LDAP is failing
by pattanaikhr＠gmail.com 08 Oct '07

08 Oct '07

Full_Name: HR Pattanaik Version: 2.2.29 OS: Windows XP Professional URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.126.136.220) When I have sign in my authentication page .It's successfully authenticate 5-6 times after that it's failing . I have searched lot of forums But I didn't get any solution for that. So I have raised this issues on your web site. Hopefully I'll get any solutions for that.Please reply me I have mention my exception is here.Please follows below. javax.naming.ServiceUnavailableException: localhost: 389; socket closed

1 0

Re: ITS#5174 openldap.schema entry not valid per RFC 4512
by ando＠sys-net.it 08 Oct '07

08 Oct '07

Not sure if ordering of optional sequence members is required by RFC 4234, but the change you suggest sounds harmless. OpenLDAP software, in this sense, is usually permissive in what is accepted and strict in what is emitted. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5164) slapi plugins prevent slapd starting.
by m.d.t.evans＠qmul.ac.uk 08 Oct '07

08 Oct '07

On Sun, 2007-10-07 at 16:29 -0700, Howard Chu wrote: > m.d.t.evans(a)qmul.ac.uk wrote: > > Full_Name: Martin Evans > > Version: 2.4.5beta > > OS: Linux > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (138.37.8.140) > > > > > > This is mentioned in #4611 but marked as fixed there. > > Now fixed in HEAD. > Thanks! I spotted your fixes to slapi/plugin.c, back-monitor/conn.c and back-monitor/database.c applied these to my version of 2.4.5beta and they seem to work fine. Martin. -- -- Dr MDT Evans, Computing Services, Queen Mary, University of London

1 0

(ITS#5174) openldap.schema entry not valid per RFC 4512
by bhanafee＠gmail.com 07 Oct '07

07 Oct '07

Full_Name: Brian Hanafee Version: 1.24.2.2 OS: Mac OS/X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.4.251.75) The final definition in /servers/slapd/schema/openldap.schema is not valid per RFC 4512. It reads: objectClass ( OpenLDAPobjectClass:6 NAME 'OpenLDAPdisplayableObject' DESC 'OpenLDAP Displayable Object' MAY displayName AUXILIARY ) Per RFC 4512, section 4.1.1, the 'kind' AUXILIARY comes before any MUST or MAY entries. The corrected entry should read: objectClass ( OpenLDAPobjectClass:6 NAME 'OpenLDAPdisplayableObject' DESC 'OpenLDAP Displayable Object' AUXILIARY MAY displayName )

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by hyc＠symas.com 07 Oct '07

07 Oct '07

richton(a)nbcs.rutgers.edu wrote: >> If this is happening even with slapd cleanly shut down then it should also >> prevent slapd from restarting, since slapd first attempts to join an existing >> environment before trying to create a new one. And that really implies that >> the rest of the environment is shot. > > Agreed, but that's a pretty awful condition to have in a long-running > slapd process. Without db_stat (easily) working, is there any hope at > finding clues as to how this might have happened, or is it just time to > rm/slapadd and hope it doesn't happen again? It doesn't seem like we can get much more info out of this. One more thing to try would be a full-debug build of libdb, so we can see exactly where it hangs when trying to join the environment. Looking thru the code, I only see one mutex to acquire the environment, and looking at your stack trace it's already past that location, but the trace could be lying. Also the mutex used to lock the environment is a regular mutex, not a persistent lock. So when all processes have closed the environment, there shouldn't be anything left to conflict with here. So most likely the environment data structures are hosed, and the thread is locking against itself. Again, we can't really tell without single-stepping thru the BDB library code. It may not be worth the effort, but that's your call. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5173) Cannot add pcache to config
by hyc＠symas.com 07 Oct '07

07 Oct '07

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: RE23/RE24/HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.168.84.21) > Submitted by: hyc > > > As reported by Ralf here > http://www.openldap.org/lists/openldap-devel/200709/msg00036.html > > Fixed in HEAD But the same problem also occurs with the translucent overlay... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5173) Cannot add pcache to config
by hyc＠OpenLDAP.org 07 Oct '07

07 Oct '07

Full_Name: Howard Chu Version: RE23/RE24/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc As reported by Ralf here http://www.openldap.org/lists/openldap-devel/200709/msg00036.html Fixed in HEAD

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 07 Oct '07

07 Oct '07

> (Of course, if you only appended to /etc/hosts then the old address is still > in there and getting used first..) "files dns" in nsswitch.conf, and no prior /etc/hosts entry. i.e., this overrode DNS to the 192.168.* interface. netstat shows that (by now, at least) this has completely taken. > If this is happening even with slapd cleanly shut down then it should also > prevent slapd from restarting, since slapd first attempts to join an existing > environment before trying to create a new one. And that really implies that > the rest of the environment is shot. Agreed, but that's a pretty awful condition to have in a long-running slapd process. Without db_stat (easily) working, is there any hope at finding clues as to how this might have happened, or is it just time to rm/slapadd and hope it doesn't happen again?

1 0

Re: (ITS#4884) Back-config inheritance issue
by hyc＠symas.com 07 Oct '07

07 Oct '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD (re23,...) > OS: irrelevant > URL: > Submission from: (NULL) (87.28.220.33) > Submitted by: ando > > > I think I've spotted a potential issue in back-config. When creating a custom > object, say an overlay, the configuration objectClass should inherit from > olcOverlayConfig. While adding the object via LDAP, however, if the ancestor > class is not explicitly listed, the derived object must provide a co_ldadd() > hook, otherwise addition fails. > Currently, the code uses all defined objectClasses and stops the first time a > hook is available and it does not fail. That was of course the designed and desired behavior... > It would be more sound, IMHO, to have something like: > > - if the structural objectClass provides a co_ldadd() hook, use it; it is that > hook's responsibility to call the superior's one if required; > > - if it doesn't, then climb the inheritance tree and call co_ldadd() for the > first occurrence of a valid one. The point is that structural classes are not the only ones that matter here, and if you're creating an entry that has a special class, you must provide the necessary handlers for that class. Climbing the inheritance tree seems an ok convenience for entries that don't explicitly list all their superior classes, but that should not have precluded the existing behavior (checking all of the explicitly listed classes, whether they are structural or auxiliary). -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4884) Back-config inheritance issue
by hyc＠symas.com 07 Oct '07

07 Oct '07

ando(a)sys-net.it wrote: > I've committed to HEAD a fix that exploits inheritance. The rationale is: > > - lookup the structural objectClass; starting from it, check it and > subordinates for a function that successfully adds the entry > > - using all objectClass values, collect all, including ancestors, that > may be of use in checking configuration. > > Passes all tests (049->051), and allows to add an overlay using only the > overlay's objectClass, provided it's derived from olcOverlayConfig. > > Please test. p. Something's wrong here, it's only checking structural classes but not auxiliary classes. This breaks proxycache now, which uses an auxiliary class for the ldadd hook when adding its private DB. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by hyc＠symas.com 07 Oct '07

07 Oct '07

Aaron Richton wrote: >> No. The BDB transaction log files don't know (or care) anything about IP >> addresses. Nothing at the slapd layer could have any direct effect on the BDB >> transaction logs. How exactly did you reconfigure the servers, did you stop >> them and restart them or did you use cn=config? > > echo 192.blahblah master.r.e >> /etc/hosts > > The master changed from 128.blahblah to 192.blahblah. Same physical > machine, just different interface. On slave4 and 6, I didn't touch slapd. (Of course, if you only appended to /etc/hosts then the old address is still in there and getting used first..) >> Might as well get the db_stat -l output for a few of them to compare. > > This isn't going well at all; they just can't join the environment. I > tried on slave1, it hung. I tried on slave4 under truss, it hung. (We're > talking >30 minutes here.) Although I swear I've run db_stat hot, I killed > db_stat (ungracefully, sadly) and stopped slapd (gracefully) on slave1, > ran db_stat again, and it hung there...and corrupted the environment to > the point where I couldn't get db_recover/slapd to run. (I ended up > blowing the slave1 database away; it's refreshing from syncrepl now.) > I've got a few more slaves that I haven't shot in the foot yet, and I only > tried this on one of the suffixes on slave{1,4}. Plenty of more > opportunities to screw this up yet if there's anything to try...I suppose > I could go for -N, or if the command line is going to be a pain, I could > join the slapd process with dbx and print ->log_stat myself (although I > might need a bit of hand holding on that)... > > [the hang on slave4] > db_stat -> libdb-4.2.so:*db_env_create(0xffbffaec, 0x0, 0x17154) > lwp_mutex_lock(0xFF0D0000) (sleeping...) > mutex type: USYNC_PROCESS > > ff307248 __db_des_get (29ac0, 29d78, 29d78, ffbff9d0, 0, ffbff9d9) + c0 > ff305780 __db_e_attach (29ac0, ffbffa94, 40400, 40000, 33e021, 29d71) + 6e0 > ff2ff434 __dbenv_open (29ac0, 0, 40400, 0, 0, 0) + 664 > 00016514 db_init (29ac0, 0, 4, 100000, ffbffba0, ff3deb54) + 64 > 00011e3c main (2, ffbffc44, ffbffc50, 29800, 0, 0) + 9a4 > 00011470 _start (0, 0, 0, 0, 0, 0) + 108 If this is happening even with slapd cleanly shut down then it should also prevent slapd from restarting, since slapd first attempts to join an existing environment before trying to create a new one. And that really implies that the rest of the environment is shot. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5164) slapi plugins prevent slapd starting.
by hyc＠symas.com 07 Oct '07

07 Oct '07

m.d.t.evans(a)qmul.ac.uk wrote: > Full_Name: Martin Evans > Version: 2.4.5beta > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (138.37.8.140) > > > This is mentioned in #4611 but marked as fixed there. Now fixed in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5172) slash in dn
by ando＠sys-net.it 07 Oct '07

07 Oct '07

reinhold.may(a)gmx.de wrote: > I'm fairly new to OpenLDAP and hope I've not misunderstood things... in that > case: sorry. > > I've been trying to import the following .ldif: > > dn: dc=somedomain,dc=org > objectclass: top > objectclass: dcObject > objectclass: organization > o: somedomain LDAP > dc: somedomain > > dn: ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: organizationalUnit > ou: My address book > > dn: ou=With/Slash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: organizationalUnit > ou: Medical > > dn: cn=With/Slash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > objectclass: mozillaAbPersonAlpha > cn: With/Slash > sn: With/Slash The above LDIF is inconsistent: the "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" entry is repeated, and in the first occurrence it is inconsistent: the distinguished value "With/Slash" is not present in the entry, there's a "Medical" instead. I suspect you messed things up when sanitizing your data. > > The "/" results into the following error message: > > ldap_add: No such object (32) > additional info: Parent does not exist This error means that the parent of the entry you're trying to add does not exist. Here "parent" means the entry immediately below the one you're trying to add, so assuming you're trying to add "cn=With/Slash,ou=My address book,dc=somedomain,dc=org", what appears to be missing is "ou=My address book,dc=somedomain,dc=org". Are you sure it exists? By looking at the server's logs at "stats,trace" level, can you tell what DN is being looked up for the parent? > If my last entry reads: > > dn: cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > objectclass: mozillaAbPersonAlpha > cn: WithoutSlash > sn: WithoutSlash > > slapd accepts the entry and adds it to its directory. > > I've read RFCs 2849 (about LDIF) and 2253 (about DNs) and can't even find "/" to > be a special character. But just in case it was forgotten, I tried to represent > it as "\/" and "\2f" but neither solution helped. Yes, it's not. Using OpenLDAP 2.3 code, I can correctly parse the DN you suspect to trigger the unexpected behavior you reported: $ slapdn 'cn=With/Slash,ou=My address book,dc=somedomain,dc=org' DN: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> check succeeded normalized: <cn=with/slash,ou=my address book,dc=somedomain,dc=org> pretty: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> $ ./libraries/libldap/dntest 'cn=With/Slash,ou=My address book,dc=somedomain,dc=org' ldap_rdn2str() = "cn=With/Slash" ldap_rdn2str() = "ou=My address book" ldap_rdn2str() = "dc=somedomain" ldap_rdn2str() = "dc=org" ldap_dn2str(ldap_str2dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org")) = "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ldap_dn2domain("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "somedomain.org" ldap_dn2ufn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "With/Slash, My address book, somedomain.org" ldap_dn2dcedn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "/dc=org/dc=somedomain/ou=My address book/cn=With\/Slash" ldap_dcedn2dn("/dc=org/dc=somedomain/ou=My address book/cn=With\/Slash") = "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ldap_dn2ad_canonical("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "somedomain.org/My address book/With\/Slash" ldap_explode_dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org"): "cn=With/Slash" ldap_explode_rdn("cn=With/Slash") 'cn=With/Slash' ldap_explode_rdn("cn=With/Slash") (no types) "With/Slash" "ou=My address book" ldap_explode_rdn("ou=My address book") 'ou=My address book' ldap_explode_rdn("ou=My address book") (no types) "My address book" "dc=somedomain" ldap_explode_rdn("dc=somedomain") 'dc=somedomain' ldap_explode_rdn("dc=somedomain") (no types) "somedomain" "dc=org" ldap_explode_rdn("dc=org") 'dc=org' ldap_explode_rdn("dc=org") (no types) "org" ldap_explode_dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") (no types): "With/Slash" "My address book" "somedomain" "org" "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" == "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ? yes p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5172) slash in dn
by reinhold.may＠gmx.de 07 Oct '07

07 Oct '07

Full_Name: Reinhold May Version: 2.3.35 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.216.115.71) I'm fairly new to OpenLDAP and hope I've not misunderstood things... in that case: sorry. I've been trying to import the following .ldif: dn: dc=somedomain,dc=org objectclass: top objectclass: dcObject objectclass: organization o: somedomain LDAP dc: somedomain dn: ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: organizationalUnit ou: My address book dn: ou=With/Slash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: organizationalUnit ou: Medical dn: cn=With/Slash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha cn: With/Slash sn: With/Slash The "/" results into the following error message: ldap_add: No such object (32) additional info: Parent does not exist If my last entry reads: dn: cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha cn: WithoutSlash sn: WithoutSlash slapd accepts the entry and adds it to its directory. I've read RFCs 2849 (about LDIF) and 2253 (about DNs) and can't even find "/" to be a special character. But just in case it was forgotten, I tried to represent it as "\/" and "\2f" but neither solution helped.

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 07 Oct '07

07 Oct '07

> No. The BDB transaction log files don't know (or care) anything about IP > addresses. Nothing at the slapd layer could have any direct effect on the BDB > transaction logs. How exactly did you reconfigure the servers, did you stop > them and restart them or did you use cn=config? echo 192.blahblah master.r.e >> /etc/hosts The master changed from 128.blahblah to 192.blahblah. Same physical machine, just different interface. On slave4 and 6, I didn't touch slapd. > Might as well get the db_stat -l output for a few of them to compare. This isn't going well at all; they just can't join the environment. I tried on slave1, it hung. I tried on slave4 under truss, it hung. (We're talking >30 minutes here.) Although I swear I've run db_stat hot, I killed db_stat (ungracefully, sadly) and stopped slapd (gracefully) on slave1, ran db_stat again, and it hung there...and corrupted the environment to the point where I couldn't get db_recover/slapd to run. (I ended up blowing the slave1 database away; it's refreshing from syncrepl now.) I've got a few more slaves that I haven't shot in the foot yet, and I only tried this on one of the suffixes on slave{1,4}. Plenty of more opportunities to screw this up yet if there's anything to try...I suppose I could go for -N, or if the command line is going to be a pain, I could join the slapd process with dbx and print ->log_stat myself (although I might need a bit of hand holding on that)... [the hang on slave4] db_stat -> libdb-4.2.so:*db_env_create(0xffbffaec, 0x0, 0x17154) lwp_mutex_lock(0xFF0D0000) (sleeping...) mutex type: USYNC_PROCESS ff307248 __db_des_get (29ac0, 29d78, 29d78, ffbff9d0, 0, ffbff9d9) + c0 ff305780 __db_e_attach (29ac0, ffbffa94, 40400, 40000, 33e021, 29d71) + 6e0 ff2ff434 __dbenv_open (29ac0, 0, 40400, 0, 0, 0) + 664 00016514 db_init (29ac0, 0, 4, 100000, ffbffba0, ff3deb54) + 64 00011e3c main (2, ffbffc44, ffbffc50, 29800, 0, 0) + 9a4 00011470 _start (0, 0, 0, 0, 0, 0) + 108

1 0

Re: ITS#4976 test008 crash with -lmcheck
by hyc＠symas.com 06 Oct '07

06 Oct '07

Howard Chu wrote: > hyc(a)symas.com wrote: >> I suspect this is a bug in glibc mcheck's pthread support, since ElectricFence >> with EF_PROTECT_BELOW set will detect 100% of all memory underruns, and no >> such error occurs there. >> >> Also this report (which it seems the original is no longer accessible) implies >> the same problem with mcheck >> >> http://www.google.com/search?q=cache:dAqJIBQSNRQJ:groups.google.com/group/g… >> > Eh... > Looking at glibc's mcheck code > http://sourceware.org/cgi-bin/cvsweb.cgi/libc/malloc/?cvsroot=glibc > shows that it has no mutex protection at all. It is completely invalid here, > this ITS will be closed. By the way, this stzck trace confirms the problem: (gdb) info thr 17 Thread 1208023360 (LWP 4680) 0x00002ae575308491 in clone () from /lib64/libc.so.6 16 Thread 1199630656 (LWP 4679) 0x00002ae575277535 in raise () from /lib64/libc.so.6 15 Thread 1191237952 (LWP 4678) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 * 14 Thread 1182845248 (LWP 4677) 0x00002ae5752bc3b7 in memset () from /lib64/libc.so.6 13 Thread 1174452544 (LWP 4676) 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 12 Thread 1166059840 (LWP 4675) 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 11 Thread 1157667136 (LWP 4674) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 10 Thread 1149274432 (LWP 4673) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 9 Thread 1140881728 (LWP 4672) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 8 Thread 1132489024 (LWP 4671) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 7 Thread 1124096320 (LWP 4670) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 6 Thread 1115703616 (LWP 4669) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 5 Thread 1107310912 (LWP 4665) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 4 Thread 1098918208 (LWP 4655) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 3 Thread 1090525504 (LWP 4650) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 2 Thread 1082132800 (LWP 4639) 0x00002ae5753088b8 in ?? () from /lib64/libc.so.6 1 Thread 47165004620160 (LWP 4632) 0x00002ae5746795d5 in pthread_join () from /lib64/libpthread.so.0 (gdb) thr 13 [Switching to thread 13 (Thread 1174452544 (LWP 4676))]#0 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 (gdb) bt #0 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 #1 0x00002ae5752b89b9 in mallochook () from /lib64/libc.so.6 #2 0x00002ae57410f865 in ber_memalloc_x (s=9297104, ctx=0x2ae57410f865) at ../../../head/libraries/liblber/memory.c:226 #3 0x00002ae57410fd68 in ber_dupbv_x (dst=0x46009b80, src=0x2aaaaadae240, ctx=0x0) at ../../../head/libraries/liblber/memory.c:501 #4 0x00002ae573ed26ce in ldap_bv2escaped_filter_value_x (in=0x2aaaaadae240, out=0x46009b80, inplace=0, ctx=0x933bd0) at search.c:468 #5 0x000000000043d239 in filter2bv_x (op=0x92e4c0, f=0x2aaaaadae280, fstr=0x92e538) at ../../../head/servers/slapd/filter.c:608 #6 0x000000000043a943 in do_search (op=0x92e4c0, rs=0x4600acb0) at ../../../head/servers/slapd/search.c:138 #7 0x0000000000437e5e in connection_operation (ctx=0x4600ade0, arg_v=0x92e4c0) at ../../../head/servers/slapd/connection.c:1145 #8 0x0000000000438332 in connection_read_thread (ctx=0x4600ade0, argv=0xb) at ../../../head/servers/slapd/connection.c:1271 #9 0x00002ae573ece7e7 in ldap_int_thread_pool_wrapper (xpool=0x7dae80) at ../../../head/libraries/libldap_r/tpool.c:614 #10 0x00002ae57467809e in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae5753084cd in clone () from /lib64/libc.so.6 #12 0x0000000000000000 in ?? () (gdb) thr 12 [Switching to thread 12 (Thread 1166059840 (LWP 4675))]#0 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 (gdb) bt #0 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 #1 0x00002ae5752b8a36 in freehook () from /lib64/libc.so.6 #2 0x000000000045b93d in ch_free (ptr=0x7d9370) at ../../../head/servers/slapd/ch_malloc.c:139 #3 0x000000000049accd in slap_sasl_open (conn=0x2ae5769dbe60, reopen=<value optimized out>) at ../../../head/servers/slapd/sasl.c:1395 #4 0x00000000004368d9 in connection_init (s=18, listener=0x7a2ad0, dnsname=0x4efe78 "unknown", peername=0x45808ca0 "IP=127.0.0.1:36732", flags=0, ssf=0, authid=0x0, peerbv=0x45808c80) at ../../../head/servers/slapd/connection.c:633 #5 0x00000000004332e0 in slap_listener (sl=0x7a2ad0) at ../../../head/servers/slapd/daemon.c:1823 #6 0x0000000000433489 in slap_listener_thread (ctx=0x45809de0, ptr=0x7a2ad0) at ../../../head/servers/slapd/daemon.c:1856 #7 0x00002ae573ece7e7 in ldap_int_thread_pool_wrapper (xpool=0x7dae80) at ../../../head/libraries/libldap_r/tpool.c:614 #8 0x00002ae57467809e in start_thread () from /lib64/libpthread.so.0 #9 0x00002ae5753084cd in clone () from /lib64/libc.so.6 #10 0x0000000000000000 in ?? () (gdb) Note that thread 12 is removing a block from the chunk list while thread 13 is walking the list. There is absolutely no thread safety here whatsoever. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs