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:
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'?
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.
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.
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.
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.
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.
(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 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 1 will be fixed by https://github.com/kubernetes/kubernetes/pull/27263
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 1 is merged upstream in master (post 1.3.0). A cherry-pick is here: https://github.com/openshift/origin/pull/9902
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 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.
*** Bug 1367824 has been marked as a duplicate of this bug. ***