Using Jupyter notebook version 6.4.6 on Ubuntu Focal fossa. It seems my system is giving me conflicting information about whether a jupyter notebook is running or not.
$ jupyter-notebook list
Currently running servers:
http://localhost:8888/?token=51e9067278456f7ab613 :: /home/$USER/Scripts
But jupyter is not listed in the process tree
$ ps -ef|grep jupyter
$USER 5098 3741 0 15:56 pts/0 00:00:00 grep --color=auto jupyter
and when I go to that port on my browser, nothing happens as that site cannot be reached. So why does jupyter list running servers?
Hi @barmanroys, yeah jupyter-notebook list (and jupyter-server list) can be a little sketchy since these commands are essentially enumerating files in the runtime directory.
A file is written to the directory upon the server’s startup, and removed upon the server’s graceful termination. When the server is terminated in a non-graceful manner (e.g., kill -9 <pid> (SIGKILL) or some other abnormal termination event in which the termination signal cannot be caught) the file used by list can be orphaned and will essentially remain in effect until manually removed.
The directory in which these files are written can be identified using jupyter --paths and looking at the runtime: entry. In that directory will be files of the form nbserver-<pid>.json (or jpserver-<pid>.json if relative to a jupyter lab launch (when the lab version is >= 3.0 since that uses jupyter-server)).
If you know you have no running servers (and your ps command should be sufficient for that), then removing the orphaned xxserver-pid.json files is warranted.
3 Likes
Just to wrap up the topic of graceful termination…
Both jupyter notebook and jupyter server catch and handle SIGTERM. The graceful way to terminate a running server is to use kill <pid> with no options (SIGTERM is the default) or kill -15 <pid> (as 15 is the signal number for SIGTERM). Issuing kill -9 <pid> sends SIGKILL - which cannot be caught. Use of SIGKILL will lead to the orphaned files issue, but, worse, existing kernels and terminal sessions can also be orphaned. These kinds of things are cleaned up by the signal handler associated with SIGTERM.
Btw, each of the server applications offer a stop sub-command (e.g., jupyter server stop <port> where 8888 is the default if <port> is not specified) that sends SIGTERM to the server process. However, stop uses the output of the list command - so can suffer from the same pitfalls raised in this post. As a result, I recommend always using the PID directly via kill to terminate a server.
nohup (and, I’m assuming placing the process into the background) introduce some other wrinkles, but, if not used, issuing ctrl-c (SIGINT) can also initiate a graceful shutdown, either entering two ctrl-c sequences in quick succession, or ctrl-c followed by 'y' at the prompt (also entered within a 3-second window). (Just mentioning here for completeness.)
Note that this conversation has been fairly Unix-centric. On Windows, you’d likely use the process status application (pstat IIRC?). I think there are similar levels of process termination approaches within that application (but can’t say for sure).
1 Like