I am trying to make an alias to easily run Jupyter on a remote machine. To this end, I concocted this command:
ssh -L 5542:localhost:5542 remote
'cd ipython && .direnv/python-3.8.10/bin/jupyter notebook --no-browser --port 5542'
This works perfectly… except for one thing: Ctrl-C in the terminal does not seem to reach the jupyter-notebook
process (which asks for two Ctrl-C presses to shut down cleanly). Instead it seems to stop the shell process and close the connection, orphaning jupyter-notebook
instead of shutting it down.
I tried writing a shell script to wrap the above command (though I would really prefer to just pass the whole thing as a ssh
argument), and even tried to trap SIGINT
:
#!/bin/bash
cd "$HOME/ipython"
foo() {
echo break
}
trap foo SIGINT
.direnv/python-3.8.10/bin/jupyter notebook --no-browser --port 5542
but ssh remote run-jupyter.sh
resulted in the same behaviour: just ^C
, terminated connection, orphaned jupyter-notebook
. Notably, no break
output. So maybe the Ctrl-C shuts down my ssh
client?
Why is this happening, and how do I fix it so Ctrl-C is correctly passed to jupyter-notebook
?
(Obviously, I know I can shut down Jupyter from the webclient menu, and it will work correctly; but this is beside the point.)
The environment:
-
localhost
is Mac OS Ventura 13.2.1, running GNU bash, version 5.2.15(1)-release (x86_64-apple-darwin22.1.0) under Terminal 2.13 (447) -
remote
is Ubuntu 20.04.6 LTS, running GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
2
Answers
I figured it out. When I just log in and invoke Jupyter from the resulting shell, it works; it hints that the difference is in whether the process has a terminal or not. This led me to the
-t
option forssh
, forcing the allocation of the terminal even whenssh
is executing a command. This is the final command that works as expected:The local ssh process is (most likely) getting SIGINT when CTRL-C is pressed.
You can try changing the local shell process to not interpret the CTRL-C itself using
stty
like this:Note this remaps ctrl-x as the interrupt key, so now ctrl-c is treated as an ordinary input locally. Whether this works or not depends on the remote handling of the raw ctrl-c.