[23.0 backport] cmd/dockerd: use default SIGQUIT behaviour#44831
Merged
neersighted merged 1 commit intoJan 17, 2023
Conversation
dockerd handles SIGQUIT by dumping all goroutine stacks to standard error and exiting. In contrast, the Go runtime's default SIGQUIT behaviour... dumps all goroutine stacks to standard error and exits. The default SIGQUIT behaviour is implemented directly in the runtime's signal handler, and so is both more robust to bugs in the Go runtime and does not perturb the state of the process to anywhere near same degree as dumping goroutine stacks from a user goroutine. The only notable difference from a user's perspective is that the process exits with status 2 instead of 128+SIGQUIT. Signed-off-by: Cory Snider <[email protected]> (cherry picked from commit 0867d31) Signed-off-by: Sebastiaan van Stijn <[email protected]>
thaJeztah
added
status/2-code-review
area/daemon
Member
Author
|
@neersighted @corhere PTAL - did you want this for 23.0 only, or also back ported for 20.10? |
Member
|
I think @corhere might want it for 20.10 given the deadlock he's looking into affects that version, though as noted we can still fall back on |
corhere
approved these changes
Jan 17, 2023
Contributor
corhere
left a comment
corhere
left a comment
There was a problem hiding this comment.
I'm in no rush to backport this change to 20.10 seeing as I've found the likely root cause of those hangs and we know about the SIGABRT workaround for any future ones on 20.10.
neersighted
approved these changes
Jan 17, 2023
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
3 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.
dockerd handles SIGQUIT by dumping all goroutine stacks to standard error and exiting. In contrast, the Go runtime's default SIGQUIT behaviour... dumps all goroutine stacks to standard error and exits. The default SIGQUIT behaviour is implemented directly in the runtime's signal handler, and so is both more robust to bugs in the Go runtime and does not perturb the state of the process to anywhere near same degree as dumping goroutine stacks from a user goroutine. The only notable difference from a user's perspective is that the process exits with status 2 instead of 128+SIGQUIT.
- What I did
Removed special handling of SIGQUIT so that the default behaviour applies.
- How I did it
- How to verify it
Start dockerd in the foreground and press Ctrl+\
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)