Keywords: Jupyter Notebook | Token Management | Remote Server
Abstract: This article provides an in-depth exploration of methods for managing running Jupyter Notebook instances and their access tokens in remote server environments. By analyzing the workings of the jupyter notebook list and jupyter server list commands, combined with the file management mechanisms in the runtime directory, it explains how to reliably retrieve token information. The article also covers issues related to orphaned files due to abnormal termination and offers various practical tips, including operations within tmux or screen sessions, to help users efficiently maintain long-running Notebook sessions.
Enumeration Mechanism of Running Jupyter Notebook Instances
In remote server environments, Jupyter Notebooks are often run persistently via tmux or screen sessions, with users accessing them remotely via SSH. When there is a need to retrieve access tokens, the most straightforward method is to use the jupyter notebook list command. This command enumerates all currently running Notebook servers and displays their URLs and token information. For example, the output after executing the command might appear as follows:
Currently running servers:
http://localhost:8888/?token=abc123def456 :: /home/user/notebooksIt is important to note that this command must be executed within the correct Python environment (e.g., Conda or virtualenv); otherwise, the tokens may not be displayed correctly.
Runtime Directory and File Management
Jupyter tracks server status by creating specific files in the runtime directory. These files are typically located in the path indicated by the runtime: entry from the jupyter --paths command, with filenames following the format nbserver-<pid>.json (for Jupyter Notebook) or jpserver-<pid>.json (for Jupyter Lab >= 3.0). The file is created upon server startup and removed upon graceful termination. If the server terminates abnormally (e.g., using kill -9), the file may remain orphaned, causing the list command to show non-existent server instances.
Alternative Commands and Operational Techniques
In addition to jupyter notebook list, the jupyter server list command can be used, which supports both Jupyter Notebook and Jupyter Lab servers. Another practical technique is to press Ctrl+C once in the terminal where the Notebook is running; this triggers an interrupt handler that displays the server link and token, along with a prompt to confirm shutdown. By entering n or allowing the operation to timeout, the server resumes operation, allowing safe retrieval of the token.
Environment Dependencies and Troubleshooting
Token display depends on the correct environment activation. If the environment does not match, the list command may show only the URL without the token. Additionally, if ps aux | grep jupyter indicates that the server is running but the list command shows no output, it may be due to corrupted or residual files in the runtime directory. In such cases, inspect and clean up orphaned files to ensure command accuracy.
Practical Recommendations and Best Practices
For long-running sessions, it is advisable to use tmux or screen in combination and periodically execute jupyter notebook list to record tokens. Avoid abnormal server termination; prefer using kill <pid> (SIGTERM) or jupyter server stop <port> for graceful shutdown to prevent orphaned files and kernel leaks.