Bug 1096276 - signal 27 (SIGPROF) not passed to container using --sig-proxy [NEEDINFO]
Summary: signal 27 (SIGPROF) not passed to container using --sig-proxy
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: atomic-bugs@redhat.com
Depends On: 1087720
TreeView+ depends on / blocked
Reported: 2014-05-09 14:55 UTC by Lukáš Doktor
Modified: 2019-03-06 01:52 UTC (History)
10 users (show)

Fixed In Version: docker-1.0
Doc Type: Bug Fix
Doc Text:
Clone Of: 1087720
Last Closed: 2016-01-07 21:35:45 UTC
Target Upstream Version:
ldoktor: needinfo? (mheon)

Attachments (Terms of Use)

Description Lukáš Doktor 2014-05-09 14:55:49 UTC
+++ 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

How reproducible:

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

Actual results:

Expected results:
Received 27, ignoring...

Additional info:
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

Comment 3 Daniel Walsh 2014-05-19 20:11:59 UTC
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.

Comment 4 Chris Evich 2014-05-19 20:52:46 UTC
(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...

Comment 5 Lukáš Doktor 2014-05-20 07:58:32 UTC
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.

Comment 6 Chris Evich 2014-05-20 14:19:55 UTC
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.

Comment 7 Daniel Walsh 2014-05-25 10:16:22 UTC
William could you just add this documention to the man page.

Comment 8 Matthew Heon 2014-06-23 12:47:22 UTC
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.

Comment 9 Daniel Walsh 2014-06-23 19:27:06 UTC
We have not shipped docker-1.0 yet, so ask Lokesh to add it.

Comment 10 Matthew Heon 2014-06-25 14:09:40 UTC
Patch is in our builds of docker-1.0

Comment 11 Lukáš Doktor 2014-07-18 08:13:52 UTC
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?

Comment 12 Matthew Heon 2014-07-22 12:55:42 UTC
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.

Comment 13 Lukáš Doktor 2014-07-23 05:21:13 UTC
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).

Comment 14 Daniel Walsh 2014-09-12 17:07:31 UTC
Fixed in docker-1.2

Comment 15 Lukáš Doktor 2014-09-29 08:29:27 UTC
Hi Daniel, what is the fix? I can't find any mentioning of SIGPROF in man pages and it's not being proxified...

Comment 16 Daniel Walsh 2014-10-13 10:36:26 UTC
Just that Matt's Fixes should be in this build.

Comment 17 Lukáš Doktor 2014-10-20 12:06:11 UTC
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?


Comment 18 Daniel Walsh 2014-10-20 17:44:25 UTC
Yes sounds good to me.  Matthew is back at University.

Note You need to log in before you can comment on or make changes to this bug.