Description of problem:
When I send these signals to the running container, they are successfully passed to it. When I try the same on previously SIGSTOPped container, they are not.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. TERM1: docker run -i fedora bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 0.1; done'
2. TERM2: for AAA in `seq 1 31`; do [ $AAA -eq 9 ] || [ $AAA -eq 17 ] || [ $AAA -eq 18 ] || [ $AAA -eq 19 ] && continue ; docker kill -s $AAA $CONTAINER; sleep 0.1; done
3. TERM2: docker kill -s 19 $CONTAINER
4. TERM2: for AAA in `seq 1 31`; do [ $AAA -eq 9 ] || [ $AAA -eq 17 ] || [ $AAA -eq 18 ] || [ $AAA -eq 19 ] && continue ; docker kill -s $AAA $CONTAINER; sleep 0.1; done
5. TERM2: docker kill -s 18 $CONTAINER
1-31 (except 17, 18, 19) are received after step 2
1-31 (except 17, 19, 20, 21, 22) are received after step 4
signals 20, 21 and 22 should be received after step 4
The same behavior applies to direct kill using:
for AAA in `seq 1 31`; do [ $AAA -eq 9 ] || [ $AAA -eq 17 ] || [ $AAA -eq 18 ] || [ $AAA -eq 19 ] && continue ; kill -$AAA $PID; sleep 0.1; done
only it's impossible to SIGSTOP the container using `kill -19 $PID` so you need to do that by `docker kill` instead.
Cannot reproduce on docker-1.1.1-3 on RHEL7 or a built of the latest upstream git master.
All signals (save 17-19) are received on both invocations of the for loop.
Today I retested it on docker-1.1.2-9.el7.x86_64 using the steps with the same results (signals 20, 21, 22 were missing after resume). Are you sure the container was stopped when you sent the signals? (new output should be printed after the step 5)
Can you verify the failure still exists with docker-1.2
exact same behavior on docker-1.2.0-19.el7.x86_64...
I don't believe this is a Docker issue.
I just tested it outside of a container (two terminals running bash, normal kill instead of docker kill) and got the same results.
Given this, I'd say this is expected behavior.