reconnect to remote sagemath jupyter notebook?

[Daniel Friedan]

Over the past dozen years or so, I've used the (now deprecated) sagemath notebook for some long calculations on a server in my department.  A big practical advantage has been the ability to disconnect my browser from the notebook and then reconnect later to see the results (or see the calculation continuing).

I'm presently contemplating another long calculation.  Seeing the "deprecated" notice on the sagemath notebook login page, I asked to have JupyterHub installed on the server.   Now I can use sagemath 8.7 in a remote jupyter notebook on the server.

However, disconnecting my browser from a remote jupyter notebook aborts the calculation.

Is there any way to get reconnectability in the sagemath jupyter notebook?

Or should I stick with the deprecated sagemath notebook?

thanks,
Daniel

Daniel Friedan

[Nils Bruin]

On Wednesday, April 10, 2019 at 11:19:22 AM UTC-7, Daniel Friedan wrote:

However, disconnecting my browser from a remote jupyter notebook aborts the calculation.

That shouldn't need to happen. Jupyter notebook has configuration options for killing "idle" notebooks (for various form of "idle", including "not having a connected browser"):

https://jupyter-notebook.readthedocs.io/en/stable/config.html?highlight=idle

In addition, JupyterHub probably has its own ways of culling inactive servers, for various forms of "inactive".

I suspect this is something you'll have to fix in the configuration of JupyterHub, or perhaps in your own jupyter notebook settings.

[Daniel Friedan]

The kernel is still running.  The problem is not the culling of idle notebooks.

When I close the browser tab and then reopen the notebook, the kernel is still running but output is lost and output from ongoing calculations does not appear.  When the ongoing calculations are finished, I can interact with the notebook again.

Google tells me that this is a long-standing deficiency of Jupyter.

The (deprecated) SageMath notebook behaves properly on reconnecting, as if there was no interruption.

This behavior is indispensable to me, so I can't switch to the Jupyter notebook until Jupyter behaves properly when reconnecting.

Daniel

[Nils Bruin]

On Monday, April 22, 2019 at 5:56:42 AM UTC-7, Daniel Friedan wrote:

The kernel is still running.  The problem is not the culling of idle notebooks.

When I close the browser tab and then reopen the notebook, the kernel is still running but output is lost and output from ongoing calculations does not appear.  When the ongoing calculations are finished, I can interact with the notebook again.

Google tells me that this is a long-standing deficiency of Jupyter.

Ouch, I see. I didn't know that. I've tried and can confirm the behaviour.

The (deprecated) SageMath notebook behaves properly on reconnecting, as if there was no interruption.

This behavior is indispensable to me, so I can't switch to the Jupyter notebook until Jupyter behaves properly when reconnecting.

 

This deficiency in Jupyter is not going to make the resources available to maintain the sagenotebook, so I'm afraid the reality is going to be we're going to have to do without it. You could take a look if cocalc does a better job. It has its own notebook and I think they wrote/adapted their own ipynb frontend too.

Otherwise, a work-around would be to structure long-running computations a little differently to write state to a separate file rather than depending on logging into the notebook. The kernel doesn't seem to lose state; it's just output, so once the process has completed (which you could then see from the file), the notebook is ready for interaction again.

Another workaround is to not close the browser but instead use something like VNC or xpra to disconnect/reconnect (remotely) to your running browser.

It's pretty obvious that different behaviour of Jupyter would be the better solution, but if the deficiency has been around for a long time and you don't have definite plans to fix it yourself (I wouldn't know how to), the reality is that this will likely not change.

[Daniel Friedan]

One of the advantages of SageMath over Mathematica is SageMath's ability to run a remote notebook without continuous network connection.  The Mathematica remote kernel requires continuous connection.  It's sad that SageMath is regressing to the level of Mathematica in this respect.

Writing output to disk during a long calculation is normal at the production stage.  My problems come from intermediate sized calculations and from the testing stage of big calculations.  One wants to to be able to go back to the notebook frequently to check the output.

I've investigated cocalc.  It requires the overhead of Docker.  Also, it uses a modified version of Jupyter.  This is apparently fine for allowing interrupted network connections.  But the interface is apparently not identical.  I'm trying to proselytize for SageMath over Mathematica to members of my center who are already using Jupyter for Python coding (for Machine Learning in high energy physics).  Two versions of Jupyter won't fly.  Also, they use Machine Learning libraries that are not present in cocalc.  They can be installed in the Docker image, but too much IT support is required for that.  Running cocalc on one's laptop in addition to the server requires Docker on the laptop.  Too much trouble.

Daniel

[Nils Bruin]

On Monday, April 22, 2019 at 11:13:23 AM UTC-7, Daniel Friedan wrote:

One of the advantages of SageMath over Mathematica is SageMath's ability to run a remote notebook without continuous network connection.  The Mathematica remote kernel requires continuous connection.  It's sad that SageMath is regressing to the level of Mathematica in this respect.

I guess providing a platform for people to vent frustration about the state of third party components used in sage out of necessity due to developer shortage is also a form of support so you're welcome :-).

For future reference:

This is an issue that tracks this problem in jupyterlab:

https://github.com/jupyterlab/jupyterlab/issues/2833

It refers to the following issue, which handles "real time collaboration" in jupyterlab, and as a consequence will deal with the output-loss-on-reconnection problem:

https://github.com/jupyterlab/jupyterlab/issues/5382

The latter is under active development (and there's a branch there that supposedly has most of what is required), so perhaps we'll get this in the not-too-distant future. Note this is for JupyterLab. I'm not so sure this will be backported to jupyter notebook. I already regularly use JupyterLab for sage, python, and magma, and it seems to be working fine.

For maintainability in the future, we might want to make is even easier still to provide sagemath as a kernel to globally installed jupyters, rather than just a prepackaged one.

[Daniel Friedan]

I'm sorry if I came off as snarky.  I really am sad to be losing this functionality of the SageMath notebook.  It has served me well in several substantial (for me) calculations over the last 12 years or so.  Of course I understand that scarcity of support resources justifies switching SageMath to the Jupyter notebook.  I'll hope that the Jupyter project catches up with the SageMath noteboook in this respect before the latter becomes unusable.

Thank you for the discussion.

Daniel

[John H Palmieri]

If you're willing to use the Sage command-line interface rather than the notebook, then you might try the "screen" program, which should already be installed on linux or Mac OS X. You might remotely log in to the machine running Sage and then do "screen sage". Then you type in whatever commands you want to execute and then detach the screen. You should be able to log out, then log back in later. Then you reattach the screen so that you can see what progress has been made.

  John

[Nils Bruin]

On Monday, April 22, 2019 at 12:31:14 PM UTC-7, John H Palmieri wrote:

If you're willing to use the Sage command-line interface rather than the notebook, then you might try the "screen" program, which should already be installed on linux or Mac OS X.

And for graphical interfaces, "xpra" works surprisingly well. Yes, it's just forwarding basically bitmaps of the graphical interface, but it can do it on a per-window basis and I've found it surprisingly responsive on reasonable-but-not-super-fast network connections. They advertise it as "screen for GUI" and it works surprisingly well!

It's a bit heavy-handed for the jupyter notebook problem but it does provide a work-around for many similar scenarios as well.