search

takluyver / nbopen

Open a Jupyter notebook in the best available server
BSD 3-Clause "New" or "Revised" License
301 stars 58 forks source link

"localhost refused to connect" for some files #74

Open daniyalasyed opened 3 years ago

daniyalasyed commented 3 years ago

image

I can open all my files using jupyter notebook by opening it through cmd but SOME FILES are leading to this error of "localhost refused to connect" when I double-click on them, while others are opening fine using double-click.

Please help. It is very inconvenient.

Edit: It seems to be only happening to all the files in a specific folder.

oliver-pola commented 3 years ago

Same problem here (Win10, Python 3.8.6). Did work yesterday, stopped working today. Didn't notice any updates being installed.

If I run "nbopen filename" in shell or double click in explorer, the browser opens (so something happens), but then there is no python.exe or pythonw.exe running. So the webservice immediately stopped, leading to such message (connection refused etc.).

Quick test with some notebook in another folder: Does open, pythonw.exe stays running.

Quick test deleting checkpoints folder within the problematic folder: Did not help. What else is there folder related?

Quick test moving all else outside problem folder (maybe created files with too long names or spaces while webservise was running fine yesterday): Problem still exists.

Quick test copying problematic notebook to a new folder: Problem still exists.

takluyver commented 3 years ago

nbopen looks for an existing notebook server running on the directory containing the notebook (or any parent directory), and only opens a new server if it can't find one. But if a server has crashed, it may think that one still exists (potentially even after a restart).

You can see the list of notebook servers it thinks are running by running jupyter notebook list in a command prompt. The files describing them are in the 'runtime' directory which you can find by running jupyter --paths. Each nbserver-*.json file in there describes one running notebook server - these are normally cleaned up when you shut down a notebook server, but may not be if it crashes.

oliver-pola commented 3 years ago

As suddenly as it did appear, it also went away. No problems if I try today. If it reappesars one might try to check jupyter notebook list.

Every system has hickups like this every now and then. I don't think this is a nbopen issue.

takluyver commented 3 years ago

IIRC, the code in Jupyter checks the process ID of servers from those saved JSON files. So if there's another process now using the same PID, Nbopen thinks the notebook server is still running, and tries to use it. If that PID happens not to be in use, it realises the file is a leftover and deletes it. So it resolves itself eventually, but not predictably.

I guess nbopen could try to make an HTTP request to the server to check it's there before opening a notebook with it. That would slightly delay opening a notebook with an existing server, but avoid most cases like this where it tries to use a server that's no longer there.

oliver-pola commented 3 years ago

This seems to be a really rare problem. Although I wouldn't mind a slighly slower but more stable start, others might prefer speed.

Maybe a cmd parameter like --check-request, so nbopen could fix the problem? Or if the same page is opened again within a few minutes, think something went wrong and do a more robust start?

From what you explained, I could fix it manually today, but maybe not in a few months when it happens again and I don't immediately find this issue to refresh my knowledge :D

takluyver commented 3 years ago

I'll leave this open and might get round to addressing it over Christmas. I might make it optional, depending on how long the check takes, but I'm inclined to make the slower, more robust option the default (i.e. opt out of the extra check, not opt in), because users shouldn't have to know about it if they don't want to. Hopefully it will just be a small fraction of a second.

Or if the same page is opened again within a few minutes, think something went wrong and do a more robust start?

That kind of solution sounds tempting, but software that does different things based on the time and what you did before can be confusing. :wink: If the check is slow enough to be a problem before opening the notebook, one option would be to check after opening it, and delete the nbserver json file if it's invalid, so it doesn't have the same problem next time - still a bit mysterious, but simpler than something involving time. But :crossed_fingers: it's quick enough that checking before opening the browser is easy.