This issue was raised at: https://stackoverflow.com/questions/47987538/redis-protected-mode-no-not-persistent-data-on-disk/47993722
Launching the server process with any command line configuration directive, e.g. redis-server --port 6379, causes the default persistence settings to be reset. Although this appears to be the behavior since forever,
https://github.com/antirez/redis/blame/0b561883b48db76a78497b1bebfd9367c80e2d96/src/server.c#L3851, it doesn't seem right.
Thoughts?
Comment From: mooleshacat
I have similar issue on UB 18.04
I am about to re-enable protected mode to see if it fixes it
Will update shortly.
Comment From: oranagra
seems like a simple innocent bug. fixing it will suddenly enable persistence for many deployments who had none so far. i suppose mentioning it in the release notes will help, but the description will be rather complicated. @yossigo i'd like your input.
Comment From: yossigo
@oranagra Yes fixing it may unmask other config issues for users, but it's definitely a bug that needs to be fixed.
Comment From: mooleshacat
seems like a simple innocent bug. fixing it will suddenly enable persistence for many deployments who had none so far. i suppose mentioning it in the release notes will help, but the description will be rather complicated. @yossigo i'd like your input.
I can confirm this also, I had issues with Redis Persistance but I did not mention it as I didn't realize it was linked until a while after posting. As soon as I cleared this up, the persistance worked.
As far as this being a bug or a configuration error, I am leaning more on the side of a configuration error as the simple solution is to configure the redis instance to use a password, and only use applications with redis that work with a password.
A bug is unintended operation of the program, which does not fit this instance.
A probable good fix for Redis is to default Redis to use a password randomly generated or ask the user for a password and explain the security vulnerabilities on non-password protected instances.