Kill exec process with SIGTERM instead of SIGKILL #21
Comments
|
Why do you think this is not the correct functionality? When a context closes, that means the request or parent crashed/ended so we don't want to orphan the runc process. |
|
Yes the runc process should be killed when the context closes. My point is that it should be killed by What I'm suggesting is listening for |
|
@inoc603 ok, the hard part is that Go is the one that sends the |
instead of defering to Go's stdlib to handle context, which only sends SIGKILL when the context timed out, handle the context timeout ourselves so we can inject a custom signal first ( default to SIGTERM, and send SIGKILL after 10 seconds) to stop container more gracefully. Fix containerd#21
instead of defering to Go's stdlib to handle context, which only sends SIGKILL when the context timed out, handle the context timeout ourselves so we can inject a custom signal first ( default to SIGTERM, and send SIGKILL after 10 seconds) to stop container more gracefully. If no signal is specified, then fall back to sending SIGKILL just like stdlib. Fix containerd#21
|
Closed #28 for staleness, is this issue still relevant though? |
In
runc.Exec, here the exec command is created withexec.CommandContext, which will kill therunccommand withos.Process.Killwhen the context is done. And whenruncis killed bySIGKILL, the exec process inside the container is not stopped. I think we should sendSIGTERMmanually to stop therunccommand when we're doing exec.I only tested this with
docker-runc. Can anyone confirm whether it is the same withrunc?The text was updated successfully, but these errors were encountered: