When Redis should save a snapshot because N changes were made in the last M minutes, this status is only cleared when the background save succeeds. If it is not possible to create the snapshot (e.g. working directory has disappeared, so the file cannot be created), Redis continually retries a background save. A fork is made every time an attempt to create a background save is done, so when it immediately quits because of this error condition, Redis continually forks+retries.
It is an exceptional condition, but maybe we should degrade a little more graceful. Another option is of course to exit altogether when saving is not possible. An argument for this resolution could be that once a user configures saving, Redis shouldn't continue to run when this is no longer possible.
We should discuss this a little bit before continuing; users may depend on the fact that Redis doesn't exit when saving is not (or no longer) possible.
Comment From: mrb
I have actually experienced something similar to this in production, and while I don't have the answers for the best way to handle it, I'm glad it's being considered. I can say that it should be as configurable as possible -- as long as Redis can be a Single Point of failure due to lack of clustering, I want the ability to configure whether or not it's going to die this way.
Comment From: antirez
This is a very important issue indeed, btw this duplicates issue #90 AFAIK
Comment From: pietern
It doesn't exactly duplicate #90, but is closely related. If #90 is solved by continuing to run without accepting writes (for instance), the attempt to perform a BGSAVE still needs a back-off. If #90 is solved by terminating the server (not likely, this will always result in data loss), this issue is no longer relevant.
Comment From: yoav-steinberg
This is old and more or less handled as a result of #849. See b237de33d1462e81ac30277033fe2bdffe994784. Closing.