Catch SIGTERM, run cleanup#4703
Merged
MichaelEischer merged 3 commits intorestic:masterfrom Feb 22, 2024
Merged
Conversation
The previous code only ran cleanup (lock release for example) on SIGINT. For anyone running restic in a container, the signal is going to be SIGTERM which means containerized execution would leave locks behind. While this could be addressed via interposing dumb-init to translate the signal, a `kill` invocation is going to default to SIGTERM, so the same problem exists for non container users. Signed-off-by: Brian Harring <ferringb@gmail.com>
Signed-off-by: Brian Harring <ferringb@gmail.com>
Contributor
Author
|
A point of discussion here is what to do with the env var That said, it's clearly something of an internal/debugging feature, so it likely can be ignored? |
Contributor
Author
|
Also, #1064 (comment) implies SIGTERM was tested/validated; I cannot repro that (at least not for |
MichaelEischer
approved these changes
Feb 22, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The previous code only ran cleanup (lock release for example) on SIGINT. For anyone running restic in a container, the signal is going to be SIGTERM which means containerized execution would leave locks behind.
While this could be addressed via interposing dumb-init to translate the signal, a
killinvocation is going to default to SIGTERM, so the same problem exists for non container users.What does this PR change? What problem does it solve?
This change ensures restic shuts down cleanly when SIGTERM'd. It currently handles SIGINT only.
For the containerized docker image, any stopping of the container results in restic being SIGTERM'd which means it
leaves behind locks and other undesirables. This problem can also exist for CLI invocation of restic-
killall resticwould accomplish the same.Was the change previously discussed in an issue or on the forum?
Ish. People talk in the forums of shutting restic down with SIGINT/SIGTERM (https://forum.restic.net/t/robustness-of-repository-issue-resolved/1475/3 for example), but nothing in the codebases history- that I can find- has SIGTERM awareness.
Minimally, manual testing of current restic confirms it lacks SIGTERM handling, so I assume folks were just... assuming...
Checklist
changelog/unreleased/that describes the changes for our users (see template).gofmton the code in all commits.