In loadServerConfig(), unlike other file paths like "logfile" which is checked carefully, the configuration parameter of directive "dbfilename" is not checked at all. The consequence is if users misconfigure an invalid file path like "directory/file" where "directory" does not exist, the background saving of temp DB will fail forever.
To replay the problem, first set the dbfilename to XXX/YYY, and set small "save" interval. Then use redis-cli to add some key-value pairs. You will see hundreds of following error messages in the error log:
[11107] 25 Sep 10:22:37 * Background saving started by pid 11140 [11140] 25 Sep 10:22:37 # Error moving temp DB file on the final destination: No such file or directory [11107] 25 Sep 10:22:37 # Background saving error [11107] 25 Sep 10:22:37 * 1 changes in 2 seconds. Saving... [11107] 25 Sep 10:22:37 * Background saving started by pid 11142 [11142] 25 Sep 10:22:37 # Error moving temp DB file on the final destination: No such file or directory [11107] 25 Sep 10:22:37 # Background saving error [11107] 25 Sep 10:22:37 * 1 changes in 2 seconds. Saving... [11107] 25 Sep 10:22:37 * Background saving started by pid 11144 [11144] 25 Sep 10:22:37 # Error moving temp DB file on the final destination: No such file or directory [11107] 25 Sep 10:22:37 # Background saving error
The corresponding parsing code is:
/* config.c */ 270 } else if (!strcasecmp(argv[0],"dbfilename") && argc == 2) { 271 zfree(server.dbfilename); 272 server.dbfilename = zstrdup(argv[1]);
I suggest to either add some checker to check the validity of the user input path, or at the using stage, generate the corresponding directory if not exist.
Thanks a lot! Tianyin
Comment From: antirez
Hello, is this about Redis 2.4? Because in 2.6 if this happens you start to get client errors when a write is attempted. Basically now Redis stops accepting writes if the previous RDB save attempt failed, that should be enough to protect against problems. Unfortunately the start-time check does not save us from all the issues as many failures are going to happen at runtime: unmounted disks, change of permissions, full disks, ...
Comment From: enjoy-binbin
this issue is quite old, i guess now redis should perform better in many aspects