jupyter-session-with-random-ports not terminating kernel

[samJcrawford]

I've been struggling with issues similar to #527 and #471 on two different devices. I did a little digging and noticed that after I tried (and failed) to start a repl with jupyter-run-repl, there would be a bunch of python -m ipykernel_launcher ... processes hanging around. It seems that the interrupt-process call in jupyter-session-with-random-ports doesn't properly shut down the kernel.

As a workaround, I found that adding a (sit-for 1) immediately after (interrupt-process process) seems to work. But I imagine there should be a way to ensure that the process has been shutdown properly.

[samJcrawford]

Just a quick update to this, I tried moving the (sit-for 0.2) from the jupyter-launch method which calls this function to the same point immediately after (interrupt-process process), and that seems to have worked. Given that this wait was happening anyway, perhaps this is a valid workaround for now?

By the way, if you have any thoughts on a more robust solution for launching kernels without jupyter-session-with-random-ports I'd love to have a crack at that.

[nnicandro]

It would be great to get rid of having to eventually call jupyter kernel to obtain a list of ports to use for a connection, as is done by jupyter-session-with-random-ports, but this is done mainly to support connecting to remote kernels over ssh. I haven't found a generic way to get a list of ports on a remote system through ssh without having to account for all the different kinds of remote systems that are possible. In Emacs it is easy to get a list of open ports, e.g. see jupyter-available-local-ports, but it isn't known if Emacs is installed on a remote system nor any other convenient piece of software that could be used to determine open ports (or I just haven't looked hard enough, I'm sure most systems have Python or something installed which could then be used to do something similar to jupyter-available-local-ports). It is safer to assume that Jupyter is available on those remote systems since we are connecting to a Jupyter kernel after all so I use the jupyter kernel command to determine ports.