+++ This bug was initially created as a clone of Bug #1087720 +++
Description of problem:
When I send signal 27 to the docker process, which is running with --sig-proxy=true, it's not forwarded. Other signals are...
Version-Release number of selected component (if applicable):
upstream Docker version 0.10.0, build dc9c28f/0.10.0
Steps to Reproduce:
1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done'
2. ps ax |grep docker
3. kill -27 $PID
Received 27, ignoring...
When you send any other signal (apart from 19 or 9) it works fine.
--- Additional comment from Lukas Doktor on 2014-04-15 04:59:24 EDT ---
The signal 17 is also ignored.
--- Additional comment from Lukas Doktor on 2014-05-05 03:48:25 EDT ---
The same bug is in upstream Docker version 0.10.0, build dc9c28f/0.10.0
I have a hard time believing this is a bug in the code. But more then likely this signal can not be sent, and not sure why this is a stopper.
(In reply to Daniel Walsh from comment #3)
> I have a hard time believing this is a bug in the code. But more then likely
> this signal can not be sent, and not sure why this is a stopper.
Hmm, this is possible, I am not familiar enough with GNU/Linux of that particular signal to know any better. It's entirely possible you're right and can't be passed. It's a test stopper because we hae no guidance on what should/shouldn't get proxied, simple as that. So if it's special in some way, then we can skip testing it and close this. I'll poke around on google and see if there are any answers...
I'm not sure either. The only think I know is that when you try the same using pure bash it's able to receive it (the only missing signals are:
19 SIGSTOP (puts process in background)
21 SIGTTIN (works with docker, probably xterm problem)
22 SIGTTOU (works with docker, probably xterm problem)
The 27 is handled properly using simple bash. I guess it might be used by go somehow? In such case I'd gladly accept man page modification as a solution.
Thinking about it more, I think some good docs on what to expect with --sigproxy would be probably be good enough for now. Icing on the cake would be logged debug messages or docker events regarding proxied signals. Either or both would greatly reduce the amount of guessing needed in terms of what is expected to work, what is unreliable, and what is unlikely to work.
William could you just add this documention to the man page.
Issue #1087720 tracks an identical bug in the Fedora build. In short, all signals save 17 work properly. Signal 17 is not proxied by design. I've submitted a docs patch to clarify that sig-proxy does not actually forward signal 17. Said patch didn't make it into RHEL docker-1.0 but should be in the next version.
We have not shipped docker-1.0 yet, so ask Lokesh to add it.
Patch is in our builds of docker-1.0
Hi Matthew, from the discussion I'm not sure, what the fix looks like. I found `SIGCHLD is not proxied` in the `docker-1.0.0-10.el7.x86_64` man page. How about the SIGCONT, SIGSTOP and SIGPROF (well and SIGKILL, it only kills the run/attach and the container is still running :-D)? Can you please point me to the documentation, where can I find them?
Docs have been updated to indicate that SIGSTOP and SIGKILL are not proxied, this should appear in the next RHEL build of Docker.
I'm hesitant to document the remaining few (SIGCONT and SIGPROF) given that they are technically Golang bugs - if they're fixed, the documentation would no longer be accurate.
I see. Can you please put here the BZ for golang bug so I can make test dependency (autotest-docker is able to trace BZ status and run the specific test only when BZ is resolved).
Fixed in docker-1.2
Hi Daniel, what is the fix? I can't find any mentioning of SIGPROF in man pages and it's not being proxified...
Just that Matt's Fixes should be in this build.
OK, I `man docker run` on docker-1.3.0-1.el7.HTB.x86_64 says:
Proxy received signals to the process (even in non-TTY mode). SIGCHLD, SIGSTOP, and SIGKILL are not proxied. The default is true.
Althought, Matthew, I thought about your concern with golang signals. CI should cover them so in case this test starts passing we will create bugzilla to remove the signals from man pages. Would that be acceptable?
Yes sounds good to me. Matthew is back at University.