If "redis-server" is started and killed (Ctrl+C), redis tries to create a dump file. If the redis server does not have permission to create it, it ends in an endless loop.

31852:M 16 Apr 2020 19:29:38.064 * Background saving started by pid 26010
26010:C 16 Apr 2020 19:29:38.064 # Failed opening the RDB file dump.rdb (in server root dir /etc) for saving: Permission denied
31852:M 16 Apr 2020 19:29:38.164 # Background saving error

I think it would make sense to limit this to x attempts and then just stop the server, since that's what the user intends.

Comment From: trevor211

What if redis-server was granted the permission later?

Comment From: kkmuffme

Yes, it works then, however this still is wonky like it is.

Perhaps alternatively (probably better than the original suggestion) is that redis should try to create a file in the rdb directory on start and if it fails, the start of redis should fail directly.

Comment From: oranagra

it may be a good idea, but note that persistence configuration can be changed at runtime, and so is the dir setting. at some point redis will refuse writes if it can't persist, and if it is stuck in shutdown attempt loop, the user can do SHUTDOWN NOSAVE right?

Comment From: kkmuffme

Yes it can be changed, but usually if you change it, redis has already written an rdb so there is no error there.

Comment From: yoav-steinberg

I think if redis is shutting down and it's waiting for a bg save to complete, then any non retyable failure should be enough to stop attempting the save and exit. By non retryable I mean anything that requires some user interaction to get it working (like changing permissions, changing configuration, freeing disk space, etc.).

The alternative is to keep the current retry-forever logic and force the user to deal with it by killing the process, fixing configuration or issuing a SHUTDOWN NOSAVE. This is also a valid approach.

I think adding a max tries or a timeout here isn't required and there's no real way for the user to anticipate what's a good value for such a timeout.

Comment From: madolson

Also, sending a second sigstop will halt the process. I think the current behavior of looping with an error message is OK.

Comment From: yoav-steinberg

Agreed, closing.