`jupyter-session-with-random-ports` not terminating kernel
Opened this issue · 2 comments
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.
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.
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.