Kernels connect but don't get to ready?

[tdaff]

Original report by Tony Hirst (Bitbucket: ajh59, ).

---

I'm running remote kernels on a Lego EV3 and they can be quite slow to start up; I'm wondering if that causes issues for Jupyter?

It always was hit and miss getting notebooks to receive the Kernel Ready signal (they appear to connect fine), but recently they've stopped getting Kernel Ready at all.

I'm not sure if this is a Jupyter remote kernel connection issue, or something that could be handled by remote_ikernel?

I seem to be able to connect to the remote kernel via jupyter console quite happily.

[tdaff]

Original comment by Tom Daff (Bitbucket: tdaff, GitHub: tdaff).

---

Hi Tony!

How slow is slow? I can put several minutes of delay in the kernel starting, but the notebook still connects eventually. This makes me suspect that it is something else.

Have you tried creating the kernel with the --verbose option? That should make it echo responses from the remote machine and confirm when the kernel has started.

Once you've confirmed that the kernel is running, can you check that the tunnel command exists as a child of the notebook process:

ps auxf:

 \_ /bin/zsh
 |   \_ /home/tdd20/.local/Virtualenvs/remote_ikernel/bin/python...
 |       \_ /home/tdd20/.local/Virtualenvs/remote_ikernel/bin/py...
 |           \_ /usr/bin/ssh -L 127.0.0.1:45861:127.0.0.1:45861 ...

If it is not there, you can try running the tunnel command manually to see if it spouts errors. The command used should be in the verbose output. It might also be worth running that command manually anyway as the output gets eaten.

Hopefully that will give some more clues as to what is going on...

[tdaff]

Original comment by Tony Hirst (Bitbucket: ajh59, ).

---

Yes, looked to be there.

Circumstances means we've shelved looking at notebooks and remote kernels for a while, so I'm going to have to park my further work on this for now:-( Hopefully I can come back to it after the summer, by which time Jupyter project will undoubtedly have moved on some considerable way yet again!

Thanks anyway - sorry I have to bail and for not resolving this my end.
--tony

[tdaff]

Original comment by Matthias Bussonnier (Bitbucket: Carreau, GitHub: Carreau).

---

I've hit what I believe is the same recently. It seem after adding a lot of logging that remote-ikernel block on expect('exit'). That appears to fix it for me.

I'm going to see if I can put a timeout on waiting for exit, and move on unconditionally.