Notebook: Adapting to protocol v5.1 for kernel, restoring connection, starting buffering

Created on 4 Sep 2018  Â·  16Comments  Â·  Source: jupyter/notebook

Hi, I am new to machine learning. My connection to jupyter notebook somehow does not work. I tried turning off antiviruses, I tried different browsers, I tried restarting the kernel, but nothing works. The "adapting to protocol v5.1 for kernel - restoring connection -starting buffering" is always repeating. I would be grateful for solutions.

unbenannt

All 16 comments

My notebook is running normally. But I think it's too much to log this info.

Seems it's the client side reconnects backend every 5~10 seconds.

I'm having the same issue on Windows 10. It prevents Jupyter from running at all.

Did you ever find a solution for this issue?

Is there anything on your network which could be interfering with websocket connections?

Hi dhirschfeld, to be honest, this is a little higher level than me. I use Jupyter/Python/R for statistical analysis, so my knowledge with proxy / nginx / websocket connections is not great.

Is there something specific I could check? I have an old ThinkPad I had no problem running Jupyter Notebooks on, and I recently upgraded to a new ThinkPad with Windows 10 and I can get nothing except the repetitive errors shown above. Any suggestions would be greatly appreciated... Thanks!

Hi Dave,

Speaking of this, after running through the sequence again, I received a

Websocket ping timeout after 90001 ms.

So it doesn't look as if it ever fully connects. Does that add anything?

On Fri, Nov 9, 2018 at 6:03 AM Dave Hirschfeld notifications@github.com
wrote:

Is there anything on your network which could be interfering with
websocket connections?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jupyter/notebook/issues/3895#issuecomment-437340268,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ak2b6hgrFZ9cEeXGCKP5k3VQKPRwdHXDks5utW8ngaJpZM4WYnx_
.

Additionally, if I launch it through another port

jupyter-notebook --port 9999

my kernel errors out and won't even get in a temporary running state as shown above.

Solved on my laptop.

My antivirus was actually causing Jupyter to not be able to use my system-level kernel. I believe this is due to Jupyter's browser based nature. (FYI: I was using ad-aware free)

Had the same issue. Avast antivirus deleted the python.exe file in my conda env folder. Restoring the .exe file and adding it as an exception to the antivirus program resolved the issue

Additionally, if I launch it through another port

jupyter-notebook --port 9999

my kernel errors out and won't even get in a temporary running state as shown above.

Had the same exact issue and running under a different port actually did solve the problem in my case

I've been having issues with this as well. For some further details, on Windows-10 it kept crashing so I wrote a simple 5 line example program that basically does (I can send anyone working on this the exact test data if interested):

import xarray as xr
import hvplot.xarray
goes16_file = "DR_ABI-L1b-RadF-M6C11_G16_s20191821200277_e20191821209585_c20191821210021.nc"
ds1 = xr.open_dataset(goes16_file)
ds1.hvplot.image(x='x', y='y', width=400, cmap='coolwarm',flip_yaxis=True).relabel("WR6582")

The program emits the "Adapting to protocol v5.1" message and runs as expected, but when it goes to save it emits a "starts buffering..." message and crashes all notebooks running on that kernel.

When I run the exact same code from the same clean install on native Linux it runs as expected. I forgot to check if it emitted the two messages, and will check later , BUT it runs and continues to run where it dies on the Windows box.

Any suggestions much appreciated.

@ebo - you should open a new issue as I think that's unrelated. To eliminate jupyter issues you should check your script runs from plain python on the same box where it hangs - e.g.

python myscript.py

Uninstall all the antivirus software, this helped in my case.

removing antivirus software is a very bad idea, and if you happen to be running on a corporate or government machine it is likely grounds for dismissal.

removing antivirus software is a very bad idea, and if you happen to be running on a corporate or government machine it is likely grounds for dismissal.

if a corporate / gov computer lets you remove the antivirus, it's not well configured; that means they should have other problems to deal with than blaming the employee :)

On Oct 24 2020 7:27 AM, Thomas wrote:

removing antivirus software is a very bad idea, and if you happen to
be running on a corporate or government machine it is likely grounds
for dismissal.

if a corporate / gov computer lets you remove the antivirus, it's not
well configured; that means they should have other problems to deal
with than blaming the employee :)

That may be, but you are also forgetting the fact that some users have
"elevated privileges" to do their jobs, so it is possible for them to do
things like that in limited cases. Even if they are constantly scanned,
it still leaves a small window of opportunity.

So unless you want to develop a personal relationship with the
ransomware gangs, and know that even if you pay up it might not end
there:

https://it.slashdot.org/story/20/10/01/1915213/ransomware-victims-that-pay-up-could-incur-steep-fines-from-uncle-sam

Unless you think you are smart enough to hack them back:

https://it.slashdot.org/story/20/10/01/1915213/ransomware-victims-that-pay-up-could-incur-steep-fines-from-uncle-sam

true, that's a good point

Was this page helpful?
0 / 5 - 0 ratings