6

I'm having a weird problem with Jupyter notebook running inside a WSL2 instance. Every time I start a new notebook, my first connection to localhost:8888 (or localhost:XXXX for any other port number) takes a LONG time to connect, like 5-10 minutes. Once one connection to that port has been made, however, all subsequent connections happen at a normal speed. As far as I can tell the delay is not specifically happening within the Jupyter server, as the server output doesn't show any GET requests during the waiting period:

> jupyter notebook .
[I 08:29:21.282 NotebookApp] Authentication of /metrics is OFF, since other authentication is disabled.
[W 08:29:21.729 NotebookApp] All authentication is disabled.  Anyone who can connect to this server will be able to run code.
[I 08:29:21.732 NotebookApp] Serving notebooks from local directory: /home/peter/jade_poplar/code/python
[I 08:29:21.732 NotebookApp] Jupyter Notebook 6.4.0 is running at:
[I 08:29:21.732 NotebookApp] http://localhost:8888/
[I 08:29:21.732 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
...
5-10 MINUTES ELAPSE
...
[I 08:38:12.718 NotebookApp] 302 GET / (127.0.0.1) 2.110000ms

However, the issue does appear to be limited only to Jupyter: if I just listen on the port with nc -l 8888 and then point my browser to localhost:8888 the GET request shows up immediately.

I have tried random fixes to other problems that I found on SE, eg. this one, but to no avail. Any advice, or even a suggestion as to where to start looking, would be greatly appreciated! This is driving me bonkers, although I am getting a lot of chess in while I wait for my notebooks to load :D

proof_by_accident
  • 111
  • 4
  • Is there any chance that `/home/peter/jade_poplar/code/python` is symlinked to anywhere on `/mnt/c` or any other Windows drive? I'm not familiar with how Jupyter notebook files are stored, but if it utilizes many small files, then slow 9P performance could be the problem. I've seen 10 minutes, for example, for a `git clone` of the WSL2 Linux kernel. – NotTheDr01ds Aug 15 '21 at 19:34
  • That's a good idea, but unfortunately it doesn't seem to be the case. I do have some symlinks higher up in the directory tree, but the problem occurs even without those. – proof_by_accident Aug 18 '21 at 06:33
  • Since it sounds like there *were* some symlinks in the tree, can you do a sanity-check `df -T /home/peter/jade_poplar/code/python` (or where ever the notebook files are located now)? Thanks! – NotTheDr01ds Aug 18 '21 at 12:23
  • 1
    @NotTheDr01ds Sure thing! `/dev/sdb ext4 251G 61G 178G 26%` – proof_by_accident Aug 19 '21 at 23:33
  • Ok, so filesystem performance doesn't look to be the problem. I'm out of ideas for solutions, but *perhaps* some troubleshooting ideas. I don't use Jupyter, but would any code from Notebooks get executed on startup? Or just when accessed? I'm wondering if you can (or should) do something like a binary search where you move half the notebooks out of Jupyer temporarily, restart, and see if the problem resolves. If not, then swap the two sets of notebooks (those in the directory and those moved out) to try again. I know this has to be frustrating ... – NotTheDr01ds Aug 21 '21 at 14:40
  • Sorry for dropping off! That's not a bad suggestion, but what's weird is this issue happens across multiple project directories and virtual envs so I don't think it's an issue with a particular chunk of code. I believe that there's something wacky going on with Windows firewall, but have yet to figure it out. – proof_by_accident Oct 18 '21 at 21:26
  • No worries, and welcome back! Well, firewall would be easy to test (assuming you have full control) by temporarily turning it off. But the `nc -l 8888` results are weird, as well, of course. There's a lot of additional ideas on the networking side in [this Github issue](https://github.com/microsoft/WSL/issues/4901), starting with a `speedtest-cli`. There's a *chance* that it could be Windows Defender that is running scans, but I had that problem more with WSL1 than WSL2. Might be worth adding an exclusion on the WSL folder, though, just for fun. Feel free to bounce ideas/thoughts off me. – NotTheDr01ds Oct 18 '21 at 22:19

1 Answers1

2

Old answer

I found 2 ways to get around the "waiting time" on my system.

  1. Hit Ctrl+C once after the console output hangs at Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
  2. Set the DISPLAY environment variable to nothing: DISPLAY= jupyter notebook .. Apparently, the same trick works for pip.

UPDATE 1

After some debugging I figured out, that the --no-browser option does the trick as well:

jupyter notebook --no-browser .

jupyter-notebook by default opens localhost:8888 in the browser. I assume WSL2 has problems opening the default browser, and therefore times out.

UPDATE 2

To confirm my guess, from UPDATE 1, I set up WSL to be able to open a browser window:

Using this setup jupyter-notebook starts normally and localhost:8888 is opened in firefox.

upe
  • 1,862
  • 1
  • 19
  • 33
  • Good thinking about the `DISPLAY=` issue! How did you figure it out? Was there something in the logs that mentioned the keyring? – NotTheDr01ds Feb 04 '22 at 14:15
  • Discovered it by accident, I had unset the `DISPLAY` variable and the problem didn't occur anymore. Then I remembered, that I had a similar problem with `pip`. I also came across this warning: `xdg-open: file '/home/user/.local/share/jupyter/runtime/nbserver-1993-open.html' does not exist`. – upe Feb 04 '22 at 18:04