Ctrl-C and SSH command

Question

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)

Answer 1

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 for ssh, forcing the allocation of the terminal even when ssh is executing a command. This is the final command that works as expected:

ssh -tL 5542:localhost:5542 remote \
  'cd ipython && .direnv/python-3.8.10/bin/jupyter notebook --no-browser --port 5542'

Answer 2

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:

stty intr ctrl-x

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.