Interactive window doesn't start if docker-based jupyter is running on port 8888.

[ghost]

Bug: Notebook Editor, Interactive Window, Editor cells

Hello there, we have been experiencing problems with Jupyter on VSCode. We usually work with a local jupyter notebook in docker mapped to local port of Windows 8888. We then somehow realized that when you start a notebook through VSCode, a jupyter server is started on the same port.

Steps to cause the bug to occur

1. Deploy a Jupyter Docker container docker run -p 8888:8888 jupyter/scipy-notebook
2. Everything is fine. You have your Docker-based Jupyter!
3. Open a .ipynb through VSCode
4. VSCode should start a local Jupyter server based on the interpreter on VSCode on 127.0.0.1:8888 blocking access to the Docker one

Actual behavior

According to @rchiodo on microsoft/vscode-python#8698, the port should be rolled to next port. But in this image you can see that we have two pids on 8888 (and different hostnames).

Expected behavior

The port should be rolled to next port. Feedback on UI could be great! I think that in order to roll on next port for the VSCode Jupyter Server, ports listening on 0.0.0.0 should be also taken into account.

Your Jupyter and/or Python environment

Jupyter on Python 3.7.5 Please provide as much info as you readily know

• Jupyter server running: Local
• Extension version: 2020.4.76186
• VS Code version: 1.44
• Python and/or Anaconda version: 3.7.5
• OS: Windows
• Virtual environment: N/A

Microsoft Data Science for VS Code Engineering Team: @rchiodo, @IanMatthewHuff, @DavidKutu, @DonJayamanne, @greazer

[IanMatthewHuff]

Hey @JoseAntonioIdener thanks for the detailed report.

Would you mind checking one thing quick for me? If you have your Jupyter Docker instance running on :8888. Then if you activate the conda / python evironment you are using in VSCode in just a command prompt can you try running "python -m jupyter notebook"?

[ghost]

Hey Ian, I tried but yeah, it gets up. The problem is how Windows treats 0.0.0.0 and 127.0.0.1. If no 127.0.0.1:8888 is up, then you can localhost:8888 to 0.0.0.0:8888

Edit: I updated the issue, I was really using python 3.7.5

[IanMatthewHuff]

I was mostly just interested in if the command line would roll over to a new port or if it had the same issue. I don't have a windows machine currently so I couldn't check quick. Right now we don't perform the port checking / rolling over ourselves, that's done by jupyter server when we launch it under the covers so if the same issue happens from the command line then the right spot for this fix would probably be upstream with jupyter and not in our code.

But I think that we can control on our side what port we start looking on, so maybe we can do something here about detecting this situation and passing a better option to jupyter. We'll discuss in our triage.

[amunger]

This seems to be working correctly now after trying the original repro steps on my Windows machine. Let us know if you're still having issues

[I 13:26:44.506 NotebookApp] The port 8888 is already in use, trying another port.
[I 13:26:44.508 NotebookApp] Serving notebooks from local directory: c:\\src\\test\\2
[I 13:26:44.508 NotebookApp] Jupyter Notebook 6.4.10 is running at:
[I 13:26:44.508 NotebookApp] http://localhost:8889/?