-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
server: avoid deadlocking call to (*grpc.Server).Stop #31692
Conversation
This can deadlock if we don't also shut down the listener, which happens only when we stop the stopper. At the same time, triggering the stopper already also shuts down the grpc server. Fixes cockroachdb#31690. Release note: None
Hmm, still hitting a deadlock with this. A worse one even, because now it's stuck with both ports closed & it doesn't react to SIGABRT. |
@knz something that's really weird here is that in this situation, the node definitely will not shut down cleanly (I see that from the logs), but I can see I'm going to have to look into the root cause once more, but in the meantime for discussion here's a second commit that just sends a signal to the own process which then activates the "regular" shutdown machinery. I'm curious what you think of that approach. (That one does not get stuck, I'm not sure why). |
Release note: None
The start code would also get stuck if it weren't for the "hard shutdown". I'm seeing the same deadlock where the grpc server doesn't shut down because a call to |
|
I'm confused how that happens. If a start a single node cluster, open a SQL prompt and even open a txn (unbuffered), |
(Your idea to have the process send itself SIGINT is sound -- it's an age-old trick -- and I have no concern with it.) |
The stuck goroutine is eventually reading from |
Superseded by #37668 |
This can deadlock if we don't also shut down the listener, which happens
only when we stop the stopper. At the same time, triggering the stopper
already also shuts down the grpc server.
Fixes #31690.
Release note: None