-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Child processes should be killed when Teleport session ends #4469
Labels
c-m
Internal Customer Reference
feature-request
Used for new features in Teleport, improvements to current should be #enhancements
robustness
Resistance to crashes and reliability
server-access
Milestone
Comments
aelkugia
added
feature-request
Used for new features in Teleport, improvements to current should be #enhancements
c-m
Internal Customer Reference
labels
Oct 7, 2020
@jakule you may have fixed this recently when investigating the agent forwarding tests. No rush, but when you have a moment can you check whether this still occurs with your latest changes? |
jakule
added a commit
that referenced
this issue
Feb 24, 2023
When a client sends an SSH session before the shell process ends, Teleport sends the SIGKILL signal to the subprocess. This causes the still-leaving shell to be resigned to PID 1 and live forever. This PR tried to stop the terminal first before killing the subprocess to prevent the terminal from living forever. Closes #13335 Closes #6245 Closes #4469
jakule
added a commit
that referenced
this issue
Feb 24, 2023
When a client sends an SSH session before the shell process ends, Teleport sends the SIGKILL signal to the subprocess. This causes the still-leaving shell to be resigned to PID 1 and live forever. This PR tried to stop the terminal first before killing the subprocess to prevent the terminal from living forever. Closes #13335 Closes #6245 Closes #4469
jakule
added a commit
that referenced
this issue
Feb 24, 2023
When a client sends an SSH session before the shell process ends, Teleport sends the SIGKILL signal to the subprocess. This causes the still-leaving shell to be resigned to PID 1 and live forever. This PR tried to stop the terminal first before killing the subprocess to prevent the terminal from living forever. Closes #13335 Closes #6245 Closes #4469
jakule
added a commit
that referenced
this issue
Feb 24, 2023
When a client sends an SSH session before the shell process ends, Teleport sends the SIGKILL signal to the subprocess. This causes the still-leaving shell to be resigned to PID 1 and live forever. This PR tried to stop the terminal first before killing the subprocess to prevent the terminal from living forever. Closes #13335 Closes #6245 Closes #4469
jakule
added a commit
that referenced
this issue
Mar 9, 2023
When a client sends an SSH session before the shell process ends, Teleport sends the SIGKILL signal to the subprocess. This causes the still-leaving shell to be resigned to PID 1 and live forever. This PR tried to stop the terminal first before killing the subprocess to prevent the terminal from living forever. Closes #13335 Closes #6245 Closes #4469
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
c-m
Internal Customer Reference
feature-request
Used for new features in Teleport, improvements to current should be #enhancements
robustness
Resistance to crashes and reliability
server-access
Feature Request
Teleport should act like SSH, and kill any child processes when the connection is closed (intentionally or not).
Motivation
Processes are not completely cleaned up when a Teleport session ends. Most cases are when the connection ends abruptly, such as a network drop, but customer did mentioned they did not confirm that that is always the case.
The majority of these cases are when the engineers are running 'rails console' (effectively an interactive ruby interpreter that's loaded all the libraries and dependencies of a project), because it consumes a lot of memory, and there may be multiple old consoles running on a machine.
(Internal reference, more details in Zendesk ticket: #1951)
Who's it for?
OSS User, Pro, Enterprise
The text was updated successfully, but these errors were encountered: