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
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
jpserver-<pid>.json if relative to a
jupyter lab launch (when the lab version is >= 3.0 since that uses
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.
Just to wrap up the topic of graceful termination…
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
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
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).