-
Notifications
You must be signed in to change notification settings - Fork 301
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
api/shutdown does not shutdown running kernels #578
Comments
Hi @martinRenou - the intention of the shutdown request is that kernels (and terminals) be shutdown. This is the case in Notebook and in Server. However, I am seeing some intermittency and interference when running against Server. Here's the console output of each:
Server:
One of the recent changes was to allow server extensions to hook the shutdown, and I suspect that path is encountering an issue. However, if I disable all server extensions except lab itself, I still get the If I revert the server to its 1.9 release so that it does not include the referenced PR and I revert Lab to 3.1.1 so that it doesn't include the change you referenced above, I get the following output:
If I keep the server down-level (1.9) but retain the changes made two weeks ago, I see this:
which is consistent - just that the lab change is interfering with the server's more "graceful" attempt and, thus, ,0 kernels or terminals will be shut down. This is a regression issue. What output are you seeing when calling |
This doesn't seem to be the case looking at the codebase, but I may misunderstand it. https://github.com/jupyter-server/jupyter_server/blob/90f619cf11eec842a27eec25692f9d65adccf169/jupyter_server/services/shutdown.py I don't see the I don't see errors when shutting down the server with |
Yeah, it's very subtle and I now see that this regression was introduced in #526. Previously, the exit of the io_loop triggered the I think your update via #579 is much clearer and is "moving forward" with the async method, etc. I'll take #579 for a spin within the next couple of hours, but it looks good on the surface - thank you! |
Thanks! |
Description
The
api/shutdown
end point is not shutting down the kernel sessions. This leaves the kernel processes hanging if they are not properly shut down before trying to shutdown the server.This forces us to do the following in JupyterLab prior to sending POST
api/shutdown
: https://github.com/jupyterlab/jupyterlab/pull/10843/filesExpected behavior
It might be nicer for the
api/shutdown
handler to first shut down the kernels before shutting down the server.Context
This would be useful in contexts where e.g. JupyterLab is embedded in an electron app, so that we can overwrite the "close app" button behavior so that it sends the
api/shutdown
request only, not having to shut down all kernels manually.The text was updated successfully, but these errors were encountered: