RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1096276 - signal 27 (SIGPROF) not passed to container using --sig-proxy
Summary: signal 27 (SIGPROF) not passed to container using --sig-proxy
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On: 1087720
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-09 14:55 UTC by Lukáš Doktor
Modified: 2023-09-14 02:07 UTC (History)
10 users (show)

Fixed In Version: docker-1.0
Doc Type: Bug Fix
Doc Text:
Clone Of: 1087720
Environment:
Last Closed: 2016-01-07 21:35:45 UTC
Target Upstream Version:
Embargoed:

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):
docker-0.10.0-8.el7.x86_64
docker-io-0.9.1-1.fc21.x86_64
upstream Docker version 0.10.0, build dc9c28f/0.10.0

How reproducible:
always

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:
nothing

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:
17 SIGCHLD
19 SIGSTOP (puts process in background)
20 SIGTSTP
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:

              --sig-proxy=true|false
                 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?

Regards,
Lukáš
Comment 18 Daniel Walsh 2014-10-20 17:44:25 UTC 
Yes sounds good to me.  Matthew is back at University.
Comment 20 Red Hat Bugzilla 2023-09-14 02:07:38 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Note You need to log in before you can comment on or make changes to this bug.