Stale Kernel Connection Behavior in JupyterLab 3.0
0 reputation · 22 Mar 2020, 07:24 UTC
Stale Kernel Connection Behavior in JupyterLab 3.0
JupyterLab 3.0 made the Lab interface the default and deprecated the classic Notebook UI, while introducing a modular plugin architecture and revised kernel specification metadata. The precise goal is to determine the intended lifecycle of a kernel after its notebook is closed in JupyterLab 3.x.
Documentation describes automatic language detection from kernel specs and new user settings under ~/.jupyter/lab/user/, but it does not clearly state whether a kernel should shut down when its last notebook tab closes or remain available for reuse. Front-end behavior appears inconsistent, and extension points may allow third-party packages to alter menu items or server extensions without defining kernel cleanup.
This is a design question about documented version behavior, not an incident report.
- Does JupyterLab 3.x terminate a kernel when its last associated notebook is closed?
- Is there a server configuration option that controls stale kernel shutdown across Lab and classic front-ends?
- Should extension authors declare kernel lifecycle behavior through the new plugin architecture?
