[Date Prev][Date Next]
2.4.16: sizelimit broken due to ors_slimit is set to SLAPD_DEFAULT_SIZELIMIT
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 500
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 both
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 (SLAPD_DEFAULT_SIZELIMIT).
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
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,
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.
### conf snippet ###
checkpoint 32 30
index entryUUID eq
retry="5 5 60 +"
"Without music to decorate it, time is just a bunch of boring production
deadlines or dates by which bills must be paid."
--- Frank Vincent Zappa