----- "andrew findlay" <andrew.findlay(a)skills-1st.co.uk> wrote:
> On Mon, Nov 24, 2008 at 10:02:56AM +0000, ghenry(a)OpenLDAP.org wrote:
>
> > The following man pages still talk about only slapd.conf:
>
> > Will fix.
>
> When doing so, would it be possible to avoid the duplication that
> has started showing up in the Admin Guide? One section for doing a
> job with slapd.conf and another one for the same job using cn=config
> seems like a sure-fire way to get inconsistent information. It also
> means that updates take (at least) twice as long to write.
We should maybe just pick on configuration method and stick to it throughout the whole guide.
POssibly cn=config, then point to the man pages for normal slapd.conf, or the other way round.
slapd.conf is easier for just copying and pasting, but saying that, so is an LDIF.
Gavin.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
On Mon, Nov 24, 2008 at 10:02:56AM +0000, ghenry(a)OpenLDAP.org wrote:
> The following man pages still talk about only slapd.conf:
> Will fix.
When doing so, would it be possible to avoid the duplication that
has started showing up in the Admin Guide? One section for doing a
job with slapd.conf and another one for the same job using cn=config
seems like a sure-fire way to get inconsistent information. It also
means that updates take (at least) twice as long to write.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
ghenry(a)OpenLDAP.org writes:
> Cool. I say we rewrite it all in Java, this C stuff is hard to understand ;-)
Perhaps we should take this to -devel now...
--
Hallvard
hyc(a)symas.com writes:
> Have to ensure that the default setting doesn't persist in cn=config,
> so that it will keep warning until an explicit value is set.
That's on my wish list for cn=config defaults in general.
--
Hallvard
Full_Name: Gavin Henry
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.159.59.85)
Submitted by: ghenry
The following man pages still talk about only slapd.conf:
slapacl
slapauth
slapdn
slappasswd
slaptest
Things like:
"It opens the slapd.conf(5) configuration file,"
Will fix.
Gavin.
hyc(a)symas.com wrote:
> I don't think the current fix is complete. Due to the Abandon check at 1190,
> it's possible (though extremely unlikely) for an Abandon to arrive between the
> start and end of a mod op, and cause the final decrement to be skipped still.
> Probably need to do some restructuring to catch this, I'll look at this some more.
Never mind, syncprov_op_cleanup already catches these cases.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Pierangelo Masarati wrote:
> hyc(a)symas.com wrote:
>> ando(a)sys-net.it wrote:
>>> Full_Name: Pierangelo Masarati
>>> Version:
>>> OS:
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (81.72.89.40)
>>> Submitted by: ando
>>>
>>>
>>> After heavily loading a MMR pool, valgrind finds the following:
>>>
>>> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely
>>> lo
>>> st in loss record 13 of 15
>> Most likely because we increment s_inuse at line 1250, at the beginning of a
>> non-Delete write op, and don't decrement it at the end of the op. I think this
>> should be simple to fix, will take a look.
>
> Seems to work. Thanks, p.
I don't think the current fix is complete. Due to the Abandon check at 1190,
it's possible (though extremely unlikely) for an Abandon to arrive between the
start and end of a mod op, and cause the final decrement to be skipped still.
Probably need to do some restructuring to catch this, I'll look at this some more.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc(a)symas.com wrote:
> ando(a)sys-net.it wrote:
>> Full_Name: Pierangelo Masarati
>> Version:
>> OS:
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (81.72.89.40)
>> Submitted by: ando
>>
>>
>> After heavily loading a MMR pool, valgrind finds the following:
>>
>> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely
>> lo
>> st in loss record 13 of 15
>
> Most likely because we increment s_inuse at line 1250, at the beginning of a
> non-Delete write op, and don't decrement it at the end of the op. I think this
> should be simple to fix, will take a look.
Seems to work. 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
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
ando(a)sys-net.it wrote:
> Full_Name: Pierangelo Masarati
> Version:
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (81.72.89.40)
> Submitted by: ando
>
>
> After heavily loading a MMR pool, valgrind finds the following:
>
> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely
> lo
> st in loss record 13 of 15
Most likely because we increment s_inuse at line 1250, at the beginning of a
non-Delete write op, and don't decrement it at the end of the op. I think this
should be simple to fix, will take a look.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/