Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1341450 - 'oc run/attach' with '-i --tty' misses sub-command in prompt message after interrupted
Summary: 'oc run/attach' with '-i --tty' misses sub-command in prompt message after in...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OKD
Classification: Red Hat
Component: Pod
Version: 3.x
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Stefan Schimanski
QA Contact: DeShuai Ma
URL:
Whiteboard:
: 1367824 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-01 05:37 UTC by Xingxing Xia
Modified: 2016-09-19 13:56 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-19 13:56:00 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Xingxing Xia 2016-06-01 05:37:05 UTC
Description of problem:
'oc run' with '-i --tty' cannot exit the session when given a hanging command. We have to delete the pod in another terminal to let it exit

Version-Release number of selected component (if applicable):
oc v1.3.0-alpha.1-41-g681170a
kubernetes v1.3.0-alpha.1-331-g0522e63

How reproducible:
Always

Steps to Reproduce:
1. oc login, create project
2. oc run with '-i --tty', give a hanging command, e.g. bash -c "sleep 10d"
$ oc run pod1 --image openshift/origin --generator run-pod/v1 -i --tty --command=true -- bash -c "sleep 10d"
Waiting for pod xxia-proj/pod1 to be running, status is Pending, pod ready: false
...

Hit enter for command prompt


^C
^[[C

Actual results:
2. Ctrl+C cannot let the connection session exit (We have to delete the pod in another terminal to let it exit)

Expected results:
2. Ctrl+C should be able to let the session exit (compare with `oc exec <pod name> -i --tty -- bash -c "sleep 10d"`, in which Ctrl+C could let the session exit)

Additional info:

Comment 1 Xingxing Xia 2016-06-01 05:59:47 UTC
BTW, when session normally ends, the prompt message needs a bit of correction:
$ oc run pod2 --image openshift/origin --generator run-pod/v1 -i --tty --command=true bash
Waiting for pod xxia-proj/pod2 to be running, status is Pending, pod ready: false

Hit enter for command prompt
id: cannot find name for user ID 1000050000

[I have no name!@origin5 origin]$ exit
Session ended, resume using ' pod2 -c pod2 -i -t' command when the pod is running


Seems the message misses some word after the first single quote. It should be 'oc exec pod2 -c pod2 -i -t' or 'oc attach pod2 -c pod2 -i -t'?

Comment 2 Xingxing Xia 2016-06-02 09:57:11 UTC
Seems the problem in comment 0 (description) comes from oc attach. oc attach also reproduces:

$ cat pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod3
spec:
  containers:
  - command: ["bash", "-c", "sleep 30d"]
    image: openshift/origin
    imagePullPolicy: IfNotPresent
    name: origin
    tty: true
    stdin: true
  restartPolicy: Always

$ oc create -f pod3.yaml

$ oc get pod
NAME               READY     STATUS      RESTARTS   AGE
pod3               1/1       Running     0          10s

$ oc attach pod3 -i -t

Hit enter for command prompt

^C
^C

It cannot exit the session.

Comment 3 Xingxing Xia 2016-06-02 10:03:43 UTC
BTW in addition, from comment 2, seems the info of `oc attach` departs from the result:
$ oc attach -h
---- snipped ----
....Can be used to ... and invoke interactive commands.
---- snipped ----

Though comment 2 prompts "Hit enter for command prompt", but actually it cannot  **invoke interactive commands**.

This is a problem too.

Comment 4 Stefan Schimanski 2016-06-09 13:31:14 UTC
The situation here is a bit tricky and is due to the signal (SIGINT for ctrl-c) handling of the Linux kernel and Docker's use of pid 1 processes in containers.

In your example

  oc run ... bash -c "sleep 10"

the bash will notice that it is only one command. It will exec directly into the sleep binary. Sleep then will use the default SIGINT handler from the kernel that the rt_sysaction system call provides. Because the sleep will run as pid 1 under Docker, this default is "do nothing". Pid 1 has special handling in the kernel, for all other pids the default is "terminate the process".

If you do this instead:

  oc run ... bash -c "sleep 10; echo foo"

the bash is pid 1. But because it is a compound command, it will install a custom SIGINT handler (which actually does nothing) in order to be interruptable while waiting for one of the subcommands. In addition - much more important here - the sleep now is a sub-process of the bash, i.e. not pid 1. The sleep SIGINT handle is "terminate process". Hence, you can ctrl-c in this case as expected:

- The bash sees the SIGINT and does nothing (only interrupts its wait4 system call waiting for the sleep). 
- The sleep sees the SIGINT and calls the default handler which kills the sleep. Then the bash will notice that its child died and will terminate as well.

You can try all this directly with docker-run:

  docker run -it centos:7 sleep 10

Same behaviour, ctrl-c does not work.

Now oc-exec has its own SIGINT handler and closes the connection on SIGINT. The same is true for SSH.

Comment 5 Stefan Schimanski 2016-06-09 13:43:05 UTC
Correction about oc/kubectl-exec:

There is no special SIGINT handling. But the exec-process is spawned in a running container and it gets a different pid than 1. Hence, ctrl-c / SIGINT handling is as expected. Probably the same applies to SSH.

Comment 6 Stefan Schimanski 2016-06-09 13:45:10 UTC
Having said all this, I tend to propose that the behavior is inherent to the docker containerizer implementation and its not a bug we can (easily) fix on the client side without introducing new unexpected behavior.

Comment 7 Xingxing Xia 2016-06-12 05:48:28 UTC
(In reply to Stefan Schimanski from comment #6)
> Having said all this, I tend to propose that the behavior is inherent to the
> docker containerizer implementation and its not a bug we can (easily) fix on
> the client side without introducing new unexpected behavior.

Then we'd better to keep as it is right now.

BTW, comment 1 and comment 3 are other 2 issues, as shown when we try another image:
$ oc run webapp -i --tty --image=training/webapp --generator run-pod/v1
Waiting for pod xxia-proj/webapp to be running, status is Pending, pod ready: false

Hit enter for command prompt
 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

ls
date
^CSession ended, resume using ' webapp -c webapp -i -t' command when the pod is running

Comment 8 Stefan Schimanski 2016-06-13 07:55:28 UTC
Comment 1 was fixed upstream here: https://github.com/kubernetes/kubernetes/pull/24366

But even with this fix the output is wrong: "kubectl" hardcoded instead of oc.

Comment 9 Stefan Schimanski 2016-06-13 08:12:05 UTC
Comment 1 will be fixed by https://github.com/kubernetes/kubernetes/pull/27263

Comment 10 Stefan Schimanski 2016-06-13 08:32:19 UTC
The root cause for the workaround "Hit enter for command prompt" in Comment 3 can be found here: https://github.com/kubernetes/kubernetes/issues/27264. A fix is probably non-trivial.

Comment 11 Stefan Schimanski 2016-07-18 14:44:03 UTC
Comment 1 is merged upstream in master (post 1.3.0). A cherry-pick is here: https://github.com/openshift/origin/pull/9902

Comment 12 Stefan Schimanski 2016-07-19 14:05:34 UTC
Cherry-pick for comment 1 is merged as well.

The actual bug reported in this issue is by design of Docker containers running as pid 1. There is no fix for that other than changing fundamentally how Docker and the Kernel works. The same happens with Docker as well, as described above.

Hence, this issue is ready for QE for the comment-1 change.

Comment 13 Xingxing Xia 2016-07-20 06:44:05 UTC
Comment 1 is fixed in:
oc v1.3.0-alpha.2+6bfd721
kubernetes v1.3.0+57fb9ac
features: Basic-Auth

Now it gives sub-command "oc attach" in prompt message:
oc run webapp -i --tty --image=training/webapp --generator run-pod/v1
...
Hit enter for command prompt

ls
^CSession ended, resume using 'oc attach webapp -c webapp -i -t' command when the pod is running

Changed the title as well.

Comment 14 Andy Goldstein 2016-08-18 18:35:09 UTC
*** Bug 1367824 has been marked as a duplicate of this bug. ***


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