[Date Prev][Date Next]
Re: 2.4.16: sizelimit broken due to ors_slimit is set to SLAPD_DEFAULT_SIZELIMIT
--On Sunday, June 14, 2009 12:41 AM +0200 Christian Fischer
I've upgraded from 2.3.43 to 2.4.16 on gentoo amd64.
Syncrepl could not finnish its initial replication due to a sizelimit of
This is a bit amazing because I've set sizelimit to unlimited, and I had
no such trouble with 2.3.43.
I've played a bit with the sizelimit statement.
If sizelimit is set to a value >=0<500 the behavior is as expected,
unlimited (-1) and values >500 are ignored.
I've turned on args debugging to see if something is different between
With version 2.3.43 op->ors_slimit is set to 0 if do_search() is
executed, with version 2.4.16 op->ors_slimit is set to 500
That explains the different behavior of limits_check().
With ors_slimit set to SLAPD_DEFAULT_SIZELIMIT it runs into
servers/slapd/limits.c:1294 and ors_slimit will only set to
ors_limit->lms_s_soft if the value of ors_limit->lms_s_soft is between 1
and SLAPD_DEFAULT_SIZELIMIT -1.
I don't know why you have set ors_slimit to SLAPD_DEFAULT_SIZELIMIT but
this breaks unlimited sizelimit or size limits > SLAPD_DEFAULT_SIZELIMIT.
I think that lms_s_soft should initially be set to
SLAPD_DEFAULT_SIZELIMIT, not ors_slimit.
But as said, I don't know why you have done this and probably you had
good reasons to do so. I'm a bit confused that nobody but me had such
limit problems with 2.4.16 till now.
Attached my config snippet.
You don't show what sizelimit is in place on the *provider* which is what
would determine how syncrepl is affected.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration