notebook won't save and checkpoint

[ultradian]

I have recently run into a problem where suddenly I can no longer save and checkpoint my notebook. I am running on Debian 4.5.4-1~bpo8+1, with notebook server is 4.2.3 and Python 2.7.9 (default, Jun 29 2016, 13:08:31) [GCC 4.9.2]. Kernel is Julia 0.5.1-pre. Browser is Firefox 45.4. I recently installed nbextensions, and I'm not sure if activating that had anything to do with this. I am not sure what triggers this, only it seems to happen if I've left the page open overnight (only happened twice). The only way I know to save my edits is to manually copy and paste each change since the last checkpoint. Symptoms:

-when I select 'Save and Checkpoint' from the File menu, nothing happens.
-when I select 'Make a copy...' it opens a blank new tab and then nothing happens.
-if I restart the kernel, it does that, but still can't save
-If I try to close the browser window, it gives me the message:
This page is asking you to confirm that you want to leave - data you have entered may not be saved.
with the choice to stay on the page or leave. If I leave, all changes since the last checkpoint are lost.
-if I make a copy of the .ipynb file, I seem to be able to open and save it ok, but when I restart everything and open the original file, it still won't let me save and now says there are no checkpoints

what is the best and most helpful way (to you) for debugging this situation?

[takluyver]

That's strange. When this happens, can you look to see if there's any error displayed in either the browser's Javascript console or the terminal where you started the notebook?

[ultradian]

There are no terminal messages besides the Kernel starting which seems normal.

Javascript did yield this error when trying to save:

TypeError: IPython.notebook.metadata.toc is undefined toc2.js:92:1

There is further code there that I can send if needed.

I also noticed looking at the Javascript console the following error when opening the notebook, although I don't know its significance:

API request failed (404): Session not found: session_id=u'23aeec95-959c-4934-93d8-1ba0178bd7a7' main.min.js:12718:9
NetworkError: A network error occurred.

There are other errors as well, but these seem to occur with other notebooks that do save correctly:

TypeError: IPython.notebook.kernel is null
Stack trace:
addSaveAsWithToc@http://localhost:8888/nbextensions/toc2/toc2.js?v=20161110110608:58:10
load_ipython_extension@http://localhost:8888/nbextensions/toc2/main.js?v=20161110110608:119:5
load_extension/</<@http://localhost:8888/static/notebook

Finally, I also noticed that under the File menu, the notebook is no longer trusted, and when I try to trust it, I get the same error:

TypeError: IPython.notebook.metadata.toc is undefined toc2.js:92:1

Is this something weird with the TOC nbextension?

[takluyver]

That does sound like an issue with the TOC extension. @jcb91 and @jfbercher, you seem to have worked on that recently, does this sound familiar?

[jcb91]

Yes, this is probably toc2's fault.

This sounds pretty much like https://github.com/ipython-contrib/jupyter_contrib_nbextensions/issues/762, and, without closer inspection, seems to originate from lines in toc assuming the existence of metadata values which for some reason don't exist. One solution is probably to patch the toc2 nbextension to create default values, in case it gets mangled somehow, although it's unclear so far how the mangling happens in the first place.

[jcb91]

@ultradian, simple check would be to disable the toc2 nbextension and see if this behaviour disappears

[jfbercher]

I haven't been able to reproduce this, not the similar issue reported in ipython-contrib/jupyter_contrib_nbextensions#762. Indeed this is related to a nonexistent metadata value, though it should have been created during the extension's load. The only explanation I see is that in some very rare circumstances and for yet unknown reasons config.load fails silently.
As I said previously

It should be possible to strengthen l89-95 whith the creation of toc section, then nav_menu if both do not exist; but I would prefer to understand what happens at root.

I would still prefer to understand what happens but indeed it is possible to patch.

[jcb91]

@ultradian if you could provide a notebook which repeatably shows this behaviour, that'd be super helpful to diagnose what difficulty toc2 is actually encountering!

[ultradian]

OK. Here is what I found out:

When I turn off the toc2 extension, it does start to work again as you anticipated. If I save a new version, the new version seems good although the follow notices came up in the JS console:

1478916043230   addons.productaddons    ERROR   Request failed certificate checks: [Exception... "SSL is required and URI scheme is not https."  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: resource://gre/modules/CertUtils.jsm :: checkCert :: line 145"  data: no] Log.jsm:751:0
1478916043230   Toolkit.GMP ERROR   GMPWrapper(gmp-gmpopenh264) findUpdates() - updateTask for gmp-gmpopenh264 threw: [Exception... "SSL is required and URI scheme is not https."  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: resource://gre/modules/CertUtils.jsm :: checkCert :: line 145"  data: no] Stack trace: checkCert()@resource://gre/modules/CertUtils.jsm:145 < downloadXML/</success()@resource://gre/modules/addons/ProductAddonChecker.jsm:113 Log.jsm:751:0
1478916043745   addons.update-checker   WARN    Update manifest for {972ce4c6-7e08-4474-a285-3208198ce6fd} did not contain an updates property
Content Security Policy: The page's settings blocked the loading of a resource at about:blank ("base-uri https://github.com")

I still have a copy of a file that consistently gives the error TypeError: IPython.notebook.metadata.toc is undefined but it is 88 MB, and still 28MB if I zip it. Is there a good way to get it to you? I imagine it would be more helpful to figure out how I created it - maybe I had it open when installing Nbextensions? I did have some unusual problem installing it in #https://github.com/ipython-contrib/jupyter_contrib_nbextensions/issues/785 that I couldn't reproduce.

[jfbercher]

Hi @ultradian
Could you give a try to the update

jupyter nbextension install https://rawgit.com/jfbercher/small_nbextensions/master/toc2.zip  --user
jupyter nbextension enable toc2/main 

and report if it improves things? Look in the console if toc2 reports something about metadata. Thanks.

[ultradian]

It seems to fix every file so far. Did not notice any messages besides the initial [toc2] toc2 initialized (via notebook_loaded)

Thanks!

[jfbercher]

Just for the record: this was probably due to a race condition during notebook loading. Config was loaded, processed and metadata written to the notebook before it was fully loaded (this happened of course for large notebooks). The metada were probably overwrited during notebook load and initialization data lost.

Now the extension detects that the notebook is fully loaded (or use the notebook_loaded event) before initializing itself).

[jcb91]

@jfbercher good work 👍
I thought there might be some kind of race in there somewhere haha :)
We should also add this fix to ipython-contrib/jupyter_contrib_nbextensions#762

[ultradian]

@jfbercher https://github.com/jfbercher Yes. Great job!

On Tue, Nov 15, 2016 at 8:35 AM, Josh Barnes [email protected]
wrote:

@jfbercher https://github.com/jfbercher good work 👍
I thought there might be some kind of race in there somewhere haha :)
We should also add this fix to ipython-contrib/jupyter_
contrib_nbextensions#762
https://github.com/ipython-contrib/jupyter_contrib_nbextensions/issues/762

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/jupyter/notebook/issues/1882#issuecomment-260692864,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANfHjTmZRsIzXspT1rFk6AU0I-27JLrSks5q-d9cgaJpZM4KuCUt
.

[tylertroy]

I am experiencing the same issue but in my case it was my Ghostery Firefox extension interferring with the notebook. Even after trusting the site, this behavior did not change.

There are a couple of workarounds that I've found.

1. Disable Ghostery for the duration of your notebook work. (not ideal)
2. Use jupyter in another browser which does not use Ghostery.

I would welcome suggestions to properly configure Ghostery to avoid this behavior. In the mean time I'm using option 2. I changed the default browser for jupyter to Chrome, a browser I don't typically use.

Setting the default browser for Jupyter is straight forward, I went with the SO description below.

https://stackoverflow.com/questions/35229604/how-to-change-the-default-browser-used-by-the-ipython-jupyter-notebook-in-linux?rq=1

[takluyver]

Oh, that's annoying. I don't know why Ghostery would interfere with it.

[harmvanderheijden]

I can confirm that ghostery interferes in Jupyter, in particular with write access, and that telling it to "trust this site" is not sufficient. I have not found any other workarounds than the 2 mentioned by tylertroy

[allenyllee]

For me, it happens when all the cell's output is too long. Just clear some output to solve this.

[ThusithaDeepal]

I had the same issue,i tried these methods unfortunately it doesn't work.
At last i found a method

1. Copy your filename.ipynb file manully to same directory

2. Rename it with filename at about 5 characters. Then open it in jupyter notebook , and it can be saved successfully .

3. After that you can rename it to any name you want !

[Litvinov-Oleg]

I solve it by renaming column in pandas dataframe. It wouldn't like to deal with column named 'class'

[jdheinz]

I had the same problem with Jupyter Notebook not saving my work. I lost hours of work multiple times. I ended up bashing my keyboard into my bedroom door. The keys went flying across the room. I HATE Jupyter Notebook with a PASSION!!! I even had a really computer savvy friend, in this class I have to do the Jupyter Notebook assignments, look at my computer and could never figure out why it wouldn't save anything. To this day, multiple people have tried and never figured it out.

[aparente-nurix]

I'm also experiencing this issue on Windows 10. Seems to happen when my notebooks get too long, I've had to resort to copy/pasting all my code to a new notebook. Does anyone know if the toc2 fix mentioned above was incorporated into the most recent version of jupyter notebook/nb_conda_kernel?

nb_conda_kernel v. 2.2.2
jupyter_client 5.2.4

All running through Anaconda python 3.7 in the base environment.

I've tried interrupting/restarting the kernel and once I stop being able to save, it seems like the whole notebook becomes non-functional. I can type and select menus, but it can never reconnect the kernel or run any code blocks.

[seanny1986]

Same issue as above. Lost several hours of work yesterday, lost more than 5 hours of work today. The notebook becomes completely non-functional; restarting the kernel and reconnecting both do nothing. Sometimes I can relaunch from the terminal and recover the work, but the last two times I've tried froze my machine. Today I managed to kill the process, yesterday required a hard reset. I used to recommend jupyter notebooks to others as a good way of sharing work. Needless to say, I won't be doing that anymore.

ipykernel 4.6.1
jupyter_client 5.1.0

Anaconda python 3.6, base environment

[jasongrout]

@seanny1986 - looking at the thread above, it looks like there have been similar symptoms, but many different issues, and many different solutions, but the common thing in many of these solutions is that the problem was in a third-party extension we have no control over, not in Jupyter itself. So:

• Do you have any browser extensions or notebook extensions loaded?
• What version of the notebook do you have?
• Can you reproduce the issue reliably?
• Can you reproduce it with no browser or notebook extensions loaded, in a clean conda environment?
• What is your OS?

[jasongrout]

And one other thing - have you tried JupyterLab or nteract?

[twytock]

I'm having an issue where jupyter notebooks freeze every time they save.

My minimum example to reproduce the issue is:

1. Create clean conda environment:
   conda create -n jlab-test --override-channels --strict-channel-priority -c conda-forge -c anaconda jupyterlab

2. Open a fresh jupyter notebook.
   jupyter notebook

3. Enter print("Hello World") in the first cell and execute it (just to check that the output works)
   
   

4. Click the "save" button (see the terminal output on Fig.3).
   

5. Try to execute the first cell again. The cell never executes (Fig.4).
   

I have reproduced this issue for 3 different browsers for both jupyter notebook and jupyter lab.

I am currently running jupyter on a remote server. I reproduced the issue both using X11 forwarding, and using the port forwarding to my local machine.

Versions:
OS : Debian GNU/Linux 9.12 (stretch)
Mozilla Firefox 68.6.0esr
Safari Version 13.1 (15609.1.20.111.8)
Chrome Version 81.0.4044.138 (Official Build) (64-bit)

Jupyter Lab 2.1.2
Jupyter Notebook 6.0.3

[kevin-bates]

This doesn't appear to be related to saving the notebook. Instead, it looks like the notebook server was shut down and restarted. On shutdown, it took the kernel with it (842bdd00...), then after the restart, the browser attempts to send a request to that same kernel - only to find the server doesn't know about (status code 404).

Why is the notebook server being restarted?

[twytock]

@kevin-bates
Thanks for responding. I think I made a mistake in including the output of a previous session. I'm attaching the portion of the screen shot that relates to the session I was running:

I will note that sometimes after 5-10 minutes, the server seems to come back online.

[twytock]

@kevin-bates
Thanks for responding. I think I made a mistake in including the output of a previous session. I'm attaching the portion of the screen shot that relates to the session I was running:

I will note that _sometimes_ after 5-10 minutes, the server seems to come back online.

Upon further investigation, the issue appears to be I/O operations on a mounted disk, not with Jupyter itself. Notebooks work just fine on the initial disk, but I/O operations on the mounted disk appear to be PAINFULLY slow.