[Bug]: code server goes to "Sleeping State" when closing the browser

[ky1emoon]

Is there an existing issue for this?

• I have searched the existing issues

OS/Web Information

• Web Browser: Chrome
• Local OS: Windows 11
• Remote OS: Ubuntu 20.04
• Remote Architecture: amd64
• code-server --version: 4.7.0

Steps to Reproduce

1. open code-server (I'm using k8s and run the pod with cpu limit N)
2. run some heavy cpu-bound job in the terminal of code-server client (something like stress -c N)
3. close the browser
4. code-server (parent pid) and child processes including cpu-bound job go to sleeping state occassionally.

Expected

The server should be in a running state regardless of client connection

Actual

The code-server process should be in a running state but occasionally goes to a sleeping state.
This leads to other terminal child processes also going to a sleeping state.

Logs

Screenshot/Video

Does this issue happen in VS Code or GitHub Codespaces?

• I cannot reproduce this in VS Code.
• I cannot reproduce this in GitHub Codespaces.

Are you accessing code-server over HTTPS?

• I am using HTTPS.

Notes

I wonder if this is expected behavior.

[ky1emoon]

I believe this might be related to microsoft/vscode-remote-release#3096, but not sure.

[jsjoeio]

🤔 if that is related and it is upstream, we not be able to do much. cc @code-asher in case you have any thoughts/ideas!

[code-asher]

What do you mean by the process going into a sleeping state? I think VS Code kills terminal processes if they are not reconnected within a timeout, could that be the cause?

[Creling]

Well, I think background jobs should be guaranteed alive by tmux, screen or something similiar, but not code-server.

If you ssh to a remote server and run some jobs, you should not expect it to keep working after closing the ssh connection, so do code-server.

[code-asher]

Ah so the issue is that code-server is not terminating jobs when closing the browser?

The reason they stay alive is in case the browser temporarily loses connectivity so it can reconnect the terminals once the network comes back up.

It is supposed to eventually kill the jobs after a timeout I believe (I think it is five minutes).