runtime icon indicating copy to clipboard operation
runtime copied to clipboard

docker kill SIGQUIT SIGILL SIGBUS SIGFPE SIGSEGV SIGPIPE are not forwarded corretly.

Open jcvenegas opened this issue 8 years ago • 3 comments

Description of problem

These signals are not forwarded to the runtime, if docker kill SIGNAL is used. Example:

docker run --runtime cc-runtime --name NAME -dt busybox sh -c 'trap "exit SIGNAL" SIGNAL ; while : ; do sleep 1; done'
docker kill -s SIGNAL NAME

Expected result

The workload is forwarded to the workload

Actual result

docker sends the signal directly to the process ( in our case cc-shim) but cc-shim does not forward this signals (which is good) .

jcvenegas avatar Oct 26 '17 21:10 jcvenegas

@jcvenegas why is that good that we don't forward those signals ? And also, why is that an issue if you consider the behavior as something we should expect ?

sboeuf avatar Oct 26 '17 21:10 sboeuf

@sboeuf IMO it is good for the cc-shim to not forward signals to like SIGSEGV because will not know if is an external signal or a real SIGSEGV. I think is still an issue/limitation because it does not cover the behavior seen when using runc.

  1. Will need to reconsider what signals would not being forwarded by the cc-shim.
  2. In the case of docker if we dont find a way to do it by cc-shim. We should consider send a PR to docker/containerd to use the runtime instead of send the signal directly to the workload (cc-shim).

So that the flow to send those signals be: docker kill -> contianerd -> cc-runtime kill -> proxy -> agent -> workload

jcvenegas avatar Oct 27 '17 14:10 jcvenegas

Also it will be better to send the SIGSTOP through the runtime. Today seems that is working but because that not possible to catch that signal, the shim is being stopped but not the real workload.

jcvenegas avatar Oct 27 '17 14:10 jcvenegas