Jupyter Lab gets killed with message "received signal 15, stopping"

JupyterLab
1

I start Jupyter Lab on a Server with jupyter lab --port=8888 --no-browser --ip=0.0.0.0 and initially it works. It runs on a Debian Server and I use --ip=0.0.0.0 for port forwarding.

Several times I had colleagues complaining that they have problems with connecting to the Jupyter Lab. In the log I see for example:

[D 2021-06-08 11:42:29.897 ServerApp] 200 GET /favicon.ico (127.0.0.1) 1.62ms
[C 2021-06-08 11:55:46.856 ServerApp] received signal 15, stopping
[I 2021-06-08 11:55:46.858 ServerApp] Shutting down 0 kernels
[I 2021-06-08 11:55:46.858 ServerApp] Shutting down 0 terminals
[D 2021-06-08 12:26:16.209 ServerApp] Searching ['...REMOVED...', '...REMOVED.../.jupyter', '...REMOVED.../venv/etc/jupyter', '/usr/local/etc/jupyter', '/etc/jupyter'] for config files

This received signal 15, stopping I find several times in the log. And it correlates with the time of the complaints. Don’t have a clue where this signal is coming from. Any hints where I could have a look to further investigate the issue?

2

Are you managing the server yourself? What else is running on there? Have you checked the system logs for any warnings or errors? How are you managing all your users- do they have separate accounts and are they reach running JupyterLab on different ports?

3

Yes, we do. And here it comes, I know that “we” is kind of a nightmarish setup. We are a group of researchers at our institute who just have this server for our calculations and we, as the users, gave us probably way to many rights on that server instead of having a real admin.

There is running some other stuff for scientific calculations, R including Rstudio but on a different port, most of us run Python or R code via SSH.
The journalctl doesn’t show any logs of interest during that time I see received signal 15, stopping.
Each user can reach JupyterLab on their own port.

But technically what can cause a signal 15?
As no one of us was on the server at that time it was definitely not a manual kill -9 $pid_jupyter_lab.

Edit: Ah I didn’t mention that we have jupyter lab --port=8888 --no-browser --ip=0.0.0.0 running via a systemd service. I just realized that I probably should first check the systemd options.

4

OK, Systemd is another area to investigate, since depending on which options you use it may attempt to monitor and stop/restart your process if it thinks it’s failed. Are you running systemd in system or user mode?

5

Indeed that was the area to investigate. I thought it might be a good idea to create a new user jupyterlab and run everything there (for having all jupyterlab in one place) and I was running systemd in user mode for that user.

And that was indeed the issue, the process got killed some time after I logged off with that user.
The solution was to use loginctl enable-linger (see this systemd issue).

@manics thanks for all your answers and helping me to dissect the issue :slight_smile:

1 Like
6

I got an error today while running some heavy workload in my notebook:

[C 2025-06-30 03:17:36.036 ServerApp] received signal 15, stopping
[I 2025-06-30 03:17:36.055 ServerApp] Shutting down 5 extensions
[I 2025-06-30 03:17:36.059 ServerApp] Shutting down 2 kernels
[I 2025-06-30 03:17:36.072 ServerApp] Kernel shutdown: 1de90f40-09ec-4632-8d8f-11556f56de35
[I 2025-06-30 03:17:36.075 ServerApp] Kernel shutdown: 80bc7fcd-bc40-49ba-939c-ab970cdc433b

I’m on Ubuntu-24 and default their is no ‘jupyter_notebook_config.py’, so I created one and skimmed through the file and found this:

## Time to wait for a kernel to terminate before killing it, in seconds. When a
#  shutdown request is initiated, the kernel will be immediately sent an
#  interrupt (SIGINT), followedby a shutdown_request message, after 1/2 of
#  shutdown_wait_timeit will be sent a terminate (SIGTERM) request, and finally
#  at the end of shutdown_wait_time will be killed (SIGKILL). terminate and
#  kill may be equivalent on windows.  Note that this value can beoverridden by
#  the in-use kernel provisioner since shutdown times mayvary by provisioned
#  environment.
#  Default: 5.0
# c.KernelManager.shutdown_wait_time = 5.0

## set the stdin (ROUTER) port [default: random]
#  See also: ConnectionFileMixin.stdin_port
# c.KernelManager.stdin_port = 0

#  See also: ConnectionFileMixin.transport
# c.KernelManager.transport = 'tcp'

The jupyter server prompts the python with SIGINT, if the kernel does not quits it force quits it with SIGTERM and kills the server completely using KeyboardInterrupt with python - that’s what was killing my server. Even if you have resources, linux jupyter will not let you allocate a long amount of resources of CPU. It is more strict for wsl windows i guess.