Describe the bug
In Redis 6.2.6, there's a range difference between configuring "save" through redis.conf and configuring the config option through the "CONFIG SET save" command (which we do at runtime).
https://github.com/redis/redis/blob/4930d19e70c391750479951022e207e19111eb55/src/config.c#L477 In loadServerConfigFromString(), redis uses atoi() to transform argv into an integer. https://github.com/redis/redis/blob/4930d19e70c391750479951022e207e19111eb55/src/config.c#L773 In configSetCommand(), it uses api strtoll() to transform argv into a longlong integer. This makes redis treat differently for the range of option "save" between redis.conf and CONFIG SET.
To reproduce
If we set "save" in redis.conf as: save 214748364700 1 Starting up an instance with these in redis.conf:
redis-server /etc/redis/redis.conf &
We get:
*** FATAL CONFIG FILE ERROR (Redis 6.2.6) *** Reading the configuration file, at line 380 >>> 'save 214748364700 1' Invalid save parameters
If we use default value of "save" and start up redis successfully, we can dynamically update option "save" with CONFIG SET:
redis-cli config set save "214748364700 1"
It returns "OK"
redis-cli config get save
We get:
1) "save" 2) "214748364700 1"
Suggested fix Redis should treat equally for the range of option "save" between redis.conf and CONFIG SET.
src/config.c void configSetCommand(client *c){
for (j = 0; j < vlen; j++) {
char *eptr;
long val;
- val = strtoll(v[j], &eptr, 10);
+ val = atoi(v[j], &eptr, 10);
if (eptr[0] != '\0' ||
((j & 1) == 0 && val < 1) ||
((j & 1) == 1 && val < 0)) {
sdsfreesplitres(v,vlen);
goto badfmt;
}
}
Comment From: enjoy-binbin
Note now in unstable branch, we made big changes to it (config part),
and actually now it 'save 214748364700 1' in redis.conf work in unstable branch
*** FATAL CONFIG FILE ERROR (Redis 6.2.6) ***
Reading the configuration file, at line 380
>>> 'save 214748364700 1'
Invalid save parameters
this will be part of 7.0, and i suppose we can live with it (6.2) :)
Comment From: oranagra
yes, it was like that for years, and now (redis 7.0) it's fixed. thanks for reporting.