Skip to content
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

Config option to shut down server after N seconds with no kernels #2963

Merged
merged 4 commits into from
Nov 20, 2017

Conversation

takluyver
Copy link
Member

This is something I was discussing with @minrk yesterday: allow the notebook server to shut down automatically after some time with no kernels active. This could be useful with nbopen: a notebook server can be started automatically when you double-click a notebook file, and then clean itself up automatically when you've finished using it.

This is not yet ready for merge: I think it should take all activity into account for the timeout, not just kernel activity, so it doesn't shut down while you're editing a file or using a terminal. It will probably be a few days before I have time to finish it off.

@takluyver
Copy link
Member Author

This is now ready for review: it considers kernels, terminals and API activity, so it shouldn't shut the server down if you're still doing anything.

You could configure it like this:

c.MappingKernelManager.cull_idle_timeout = 600
c.NotebookApp.shutdown_no_activity_timeout = 600

With those options, if you close a notebook tab leaving the kernel running, it will cull the kernel after 10 minutes. After another 10 minutes, if you haven't done anything else, the server will shut down.

There is currently no option to cull idle terminals, so if you leave a terminal open, the server will never shut down. We could add an option for that separately.

@takluyver takluyver added this to the 5.3 milestone Nov 2, 2017
@takluyver
Copy link
Member Author

@Carreau @gnestor @minrk ?

Copy link
Member

@Carreau Carreau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that make sens, it is an often requested feature.

@minrk
Copy link
Member

minrk commented Nov 14, 2017

Makes sense. Only thing I'd like to add is that there's already an API endpoint for retrieving activity info in services/api/handlers.py. It would be good to get this updated last_activity to the field reported there, as well, so the two stay in sync. I'm not sure what that means wrt where the last_last_activity calculation belongs. At the app level makes sense, but at the same time accessing a method on the app object from a handler doesn't seem right.

@gnestor
Copy link
Contributor

gnestor commented Nov 16, 2017

@minrk To clarify: Does the last_activity provided by services/api/handlers.py include kernel and terminal activity? Can the app get the last_activity value from there? That would simplify this quite a bit 👍

@minrk
Copy link
Member

minrk commented Nov 16, 2017

@gnestor it should be the last activity of any kind on the server as a whole i.e. exactly the same value added here in app.last_activity.

@takluyver
Copy link
Member Author

It doesn't currently include terminals, because I only added terminal activity timestamps in this PR. I'll look for a way to unify them.

@takluyver
Copy link
Member Author

I have unified them in a method on the web application object. This seemed a good compromise, as it's easily accessible both from the NotebookApp and from the API handler.

@gnestor
Copy link
Contributor

gnestor commented Nov 17, 2017

@minrk Care to take one last look and merge?

Copy link
Member

@minrk minrk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks!

@minrk minrk merged commit a2f72da into jupyter:master Nov 20, 2017
@takluyver takluyver deleted the shutdown-no-kernels branch March 13, 2018 17:42
@clkao clkao mentioned this pull request Aug 21, 2018
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants