Re: (ITS#5191) Corrupted control value when using pagedresults with subordinate database
by ando＠sys-net.it
> When using pagedresults with a subordinate database, the control value of
> the
> returned searchResDone is corrupted.
AFAIK, paged results is not supposed to work with glued databases, as its
current implementation in both back-bdb/back-hdb and back-sql relies on
internal properties of the storage to keep track of the state of a
search. The most appropriate behavior would be to ignore the control, if
not critical, or reject the operation, if critical.
I take this ITS as an action to prevent paged results from working when
impacting more than one glued database.
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
---------------------------------------
14 years, 7 months
Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ando＠sys-net.it
For the records: I seem to be ble to consistently reproduce the issue when
running slapd under valgrind; I haven't seen it yet when running the test
regularly (single CPU i386, recently).
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
---------------------------------------
14 years, 7 months
Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de
Btw, could you attach your pcache configuration to this bug?
On Mittwoch, 17. Oktober 2007, ghenry(a)suretecsystems.com wrote:
[..]
> >
> > I just did the same on my x86_64 dual core. Result: 1 failure and 99
> > passes.
> > Might be that this bug is better reproducable on a single core machine.
> > But at
> > least I was able to reproduce it now.
>
> I can run the same command above on a x86_64 dual core on Monday, as I'm
> away on business the rest of the week.
>
> >> Very strange....
> >
> > I have fixed a very similar issue recently (at least I thought I fixed
> > it :| ). I'll take a closer look tomorrow.
--
Ralf
14 years, 7 months
Re: (ITS#5189) slapadd -q breaks db_stat -c
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> I wrote:
>> Just reproduced it. Out of locks (so of course configure more), then
>> "Accessing a corrupted shared library". Will file a separate ITS, it
>> doesn't sound like slapadd in a clean directory should need 1000+ locks.
>
> ...yes it should, it was a case of writing an entry with many values
> in an indexed attribute - after the index was big enough that presumably
> few of the new values' hashes ended up on the same DB page. So, it's
> just a spurious scary error message afterwards from BerkeleyDB.
>
The "Accessing a corrupted shared library" message occurs on Linux because
it's logging an LDAP result code (80, LDAP_OTHER) as a system errno code.
Probably ought to change that...
--
-- 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/
14 years, 7 months
Re: (ITS#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no
I wrote:
> Just reproduced it. Out of locks (so of course configure more), then
> "Accessing a corrupted shared library". Will file a separate ITS, it
> doesn't sound like slapadd in a clean directory should need 1000+ locks.
...yes it should, it was a case of writing an entry with many values
in an indexed attribute - after the index was big enough that presumably
few of the new values' hashes ended up on the same DB page. So, it's
just a spurious scary error message afterwards from BerkeleyDB.
--
Regards,
Hallvard
14 years, 7 months
Re: (ITS#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no
hyc(a)symas.com writes:
> These are backend-specific considerations. Feel free to file an ITS
> against the slapd-bdb(5) manpage if you wish.
Might as well be this one. "Need to document what you are explaining
here." Probably mostly in the Admin Guide with a few notes in the
manpage.
> Any operation will acquire a lock for every single DB page it
> touches. (...)
I don't think that can be quite right. A search which traverses the
database would need an awful lot of locks. Unless for the entries
it acquires and then releases the locks for one entry at a time.
> The more work that an operation needs to do, the more pages
> it will touch, the more locks it will need. (...)
Another item would be entries needed to evaluate access controls, I
assume.
>> Sleepycat messages can be scary. I came from the slapadd "wrong dynamic
>> library" or message or whatever it was which the mailinglist says is
>> cured with more locks & lockers, so I increased those and just got
>> another error message (this ITs). So apparently, something still wrong.
>
> I'm not familiar with that message or advice.
Just reproduced it. Out of locks (so of course configure more), then
"Accessing a corrupted shared library". Will file a separate ITS, it
doesn't sound like slapadd in a clean directory should need 1000+ locks.
http://www.openldap.org/lists/openldap-software/200607/msg00305.html
>> "Not configured for the locking subsystem" sounded like a permanent
>> problem with the database build, not that it would get "reconfigured"
>> to support locking when needed. Hence this report. Oh well.
>
> The message said The Environment is not configured for locking. It
> didn't say the BDB library.
Yes, that's what I meant. The database, with its enviroment, I just
built with slapadd.
> Really there's nothing mystical or spooky here, and if you've actually
> read the BDB documentation you'll know what The Environment refers
> to. If you're using back-[bh]db without having read the BDB
> documentation, despite all the recommendations to do so, you deserve
> to be scared.
I've read it.
--
Regards,
Hallvard
14 years, 7 months
(ITS#5196) Documentation should indicate that slurpd is deprecated
by bgmilne＠staff.telkomsa.net
Full_Name: Buchan Milne
Version: REL_ENG_2_3 (post-2.3.38)
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (196.15.129.131)
It is well known that slurpd is deprecated, and it has been removed from 2.4.
However, many questions arise in various support fora (case in point, #ldap on
irc.freenode.net) about setting up slurpd, and the documentation still covers
slurpd, without noting that it is deprecated (which probably contributes to
continued use of slurpd, even on 2.3).
A notice should be placed at least in the following places to this effect:
-slurpd(8)
-Admin guide chapter 14
-replica section of slapd.conf(5)
-slapd.replog(5)
14 years, 7 months
Re: (ITS#5189) slapadd -q breaks db_stat -c
by hyc＠symas.com
Hallvard B Furuseth wrote:
> hyc(a)symas.com writes:
>> h.b.furuseth(a)usit.uio.no wrote:
>>> quanah(a)zimbra.com writes:
>>>> You have to run slapd at least once before using the db_stat tool
>>>> after using slapadd -q. This is a known feature of using -q.
>>> Ah, need doc fix in slapadd.8 then.
>> What exactly are you trying to do?
>
> Playing around, mostly.
>
>> slapadd -q disables locking,
>
> I don't see that in the doc. It's reasonable to infer, except I have no
> idea why even slapadd (without -q) needs so many. I couldn't find an
> explanation of what does use locks and lockers (FAQ file 893 doesn't
> say), thus not how many I will need and which of these limits is fatal
> if I have too few. Can experiment to find out the latter, of course.
These are backend-specific considerations. Feel free to file an ITS against
the slapd-bdb(5) manpage if you wish.
In back-[bh]db there are typically up to two transactions per operation, and
each transaction uses a single locker. There's also a single reader locker per
thread. So at most you need 3 lockers per configured server thread. The BDB
default of 1000 is generally more than enough.
Any operation will acquire a lock for every single DB page it touches. The
more work that an operation needs to do, the more pages it will touch, the
more locks it will need. If you write an entry that has many indexed
attributes, or if you have substring indices on attributes with lengthy
values, you will need many locks in a single operation. While the number of
pages simultaneously held open will depend on the actual distribution of data
in the database, an operation will generally need at least one lock per DB
file. So, one for a dn2id lookup, one for an id2entry lookup, and one for each
defined index. In most cases that's all, but substring indices will generally
need a number of locks proportional to the length of the strings being indexed.
> Sleepycat messages can be scary. I came from the slapadd "wrong dynamic
> library" or message or whatever it was which the mailinglist says is
> cured with more locks & lockers, so I increased those and just got
> another error message (this ITs). So apparently, something still wrong.
I'm not familiar with that message or advice.
> "Not configured for the locking subsystem" sounded like a permanent
> problem with the database build, not that it would get "reconfigured" to
> support locking when needed. Hence this report. Oh well.
The message said The Environment is not configured for locking. It didn't say
the BDB library. Really there's nothing mystical or spooky here, and if you've
actually read the BDB documentation you'll know what The Environment refers
to. If you're using back-[bh]db without having read the BDB documentation,
despite all the recommendations to do so, you deserve to be scared.
>> so of course there's nothing for db_stat -c to report. There's no
>> breakage here.
>
--
-- 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/
14 years, 7 months
Re: (ITS#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no
hyc(a)symas.com writes:
>h.b.furuseth(a)usit.uio.no wrote:
>> quanah(a)zimbra.com writes:
>>> You have to run slapd at least once before using the db_stat tool
>>> after using slapadd -q. This is a known feature of using -q.
>>
>> Ah, need doc fix in slapadd.8 then.
>
> What exactly are you trying to do?
Playing around, mostly.
> slapadd -q disables locking,
I don't see that in the doc. It's reasonable to infer, except I have no
idea why even slapadd (without -q) needs so many. I couldn't find an
explanation of what does use locks and lockers (FAQ file 893 doesn't
say), thus not how many I will need and which of these limits is fatal
if I have too few. Can experiment to find out the latter, of course.
Sleepycat messages can be scary. I came from the slapadd "wrong dynamic
library" or message or whatever it was which the mailinglist says is
cured with more locks & lockers, so I increased those and just got
another error message (this ITs). So apparently, something still wrong.
"Not configured for the locking subsystem" sounded like a permanent
problem with the database build, not that it would get "reconfigured" to
support locking when needed. Hence this report. Oh well.
> so of course there's nothing for db_stat -c to report. There's no
> breakage here.
--
Hallvard
14 years, 7 months
