| Summary: | Terminal connections persist after navigating away | ||||||
|---|---|---|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Justin Pierce <jupierce> | ||||
| Component: | Node | Assignee: | Seth Jennings <sjenning> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Xiaoli Tian <xtian> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 3.3.0 | CC: | aos-bugs, decarr, gblomqui, jfiala, jokerman, mmccomas | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 3.9.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1430905 (view as bug list) | Environment: | |||||
| Last Closed: | 2019-07-03 15:26:34 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | 1430905 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Blocked until https://github.com/docker/docker/pull/27470 is in a version of docker we have access to *and* we've updated kube/openshift to use this new docker feature. Perhaps you have considered it already, but if all you need is the pid, why not use the exec websocket to emulate stdout < echo "THIS IS THE SH PID($$)" ? You could await a line with that pattern and extract the PID. The web console user would not need to see this output line. There is no mechanism for an external client such as the web console to send a "kill pid <x>" request. This has to be managed by the component responsible for spawning the exec session, which is currently the node. Just so I'm clear, why wouldn't another exec API call do the job? ...exec?command=kill&command=-9&command=[pid]&... This appears to work in my environment. Yes, you could do that, but you shouldn't have to. Andy is there anything the UI will actually need to do for this or is kube going to handle killing the PID that was launched for the exec when the exec closes? Should I just transfer this bug to you guys? Yeah, I would send this to Derek's team. FYI https://github.com/docker/docker/pull/27470 has merged targeted for docker 1.13. marked upcoming release as we wait for docker 1.13 still waiting on docker 1.13 get a containers bz opened to request a backport. Still waiting on backport https://bugzilla.redhat.com/show_bug.cgi?id=1430905 Backport is done, but still waiting on new docker packages for dev/test on this issue. Runway is too short for 3.6. This requires new code upstream. Targeting 3.7. Closing based on comment #15 |
Created attachment 1217427 [details] Screenshot showing /bin/sh build up Description of problem: Each time a terminal connection is opened through the web console, a /bin/sh session is left behind in the pod. These connections build up over time and do not appear to terminate. Version-Release number of selected component (if applicable): v3.3.0.32 How reproducible: 100% Steps to Reproduce: 1. Navigate to the Terminal tab of a pod 2. At the prompt enter: $ ps faux 3. Count the number of /bin/sh instances 4. Reload the browser page 5. Navigate again to the Terminal tab the pod 6. Run ps again: $ ps faux 7. Note that the number of /bin/sh instances have increased by 1 Actual results: /bin/sh instances increase each time the web console establish a new Terminal connection. Expected results: Some mechanism to ensure these /bin/sh instances do not build up over time. Additional info: