3 ms·

> cd into a git repo on your Windows side: cd /mnt/c/repos/example_git and expect a minimum of a 1 minute wait for simple repos. Yes that will be slow, don’t u

> cd into a git repo on your Windows side: cd /mnt/c/repos/example_git and expect a minimum of a 1 minute wait for simple repos. Yes that will be slow, don’t use /mnt, anything under that directly will crawl. Use /home or somewhere else and save your work there. In VSCode you can access any dir and now there’s gui support so there’s no excuse to be using /mnt now. I believe some docs on WSL do tell you this > The WSL IP Address changes on every restart.... ALWAYS. So trying to setup a local web server for testing becomes a hassle. That’s weird, I’ve never had any issues relating to running a web server. Listening on a port in WSL automatically exposes it on Windows. I’ve not had to configure anything when restarting etc.

abdusco 5y ago
I occasionally run into an issue that breaks localhost port forwarding. I can access the service that's running inside WSL2 via its actual IP (172.#.#.#) when 127.0.0.1 breaks. But that IP address changes every time WSL instance restarts. I've had to set up a scheduled task[0] to update an entry in my hosts file every time WSL is assigned a new IP address, which works well enough. [0]: https://abdus.dev/posts/fixing-wsl2-localhost-access-issue/ https://abdus.dev/posts/fixing-wsl2-localhost-access-issue/
- jayflux 5y ago
  Excuse my ignorance here but why are you using its actual IP instead of just localhost or 127.0.0.1? When starting up a local server inside of WSL I’ve never needed to do that (unless it needs to be accessed somewhere else in the network) I know the blog post says localhost redirection “often fails” but that’s just never been the case for me, and the citation it uses is just a link to the WSL issues page rather than a specific issue.
  - abdusco 5y ago
    Localhost mostly works, and I use localhost when it does work. But when it fails (once a week or so, and this keeps happening on 3 different machines running the latest/a recent Insider build), usually after the PC wakes up from sleep, I have to restart the PC to access via localhost again, which is undesirable for me because I have to spend 10 min restoring all apps & windows back to how they were. Or I can use the IP address directly and map it to a friendly hostname, in my case `wsl` and keep working. This is done behind the scenes with a scheduled task, so when I see `localhost:PORT` doesn't work, I just retry it with `wsl:PORT`. The reason I haven't linked to a specific issue is that there's just so many [*], and localhost sharing is still buggy and hasn't been fixed even after 2 years. [0]: https://github.com/microsoft/WSL/issues/5298 https://github.com/microsoft/WSL/issues/5298 [1]: https://github.com/microsoft/WSL/issues/7492 https://github.com/microsoft/WSL/issues/7492 [2]: https://github.com/microsoft/WSL/issues/6725 https://github.com/microsoft/WSL/issues/6725 [3]: https://github.com/microsoft/WSL/issues/4885 https://github.com/microsoft/WSL/issues/4885 [4]: https://github.com/microsoft/WSL/issues/5439 https://github.com/microsoft/WSL/issues/5439 and many more.
    - jayflux 5y ago
      Fair enough, hopefully that gets fixed, my machine doesn’t go to sleep that often so maybe that’s why I haven’t been affected. My servers are not usually long-running, I only use them when developing so that’s probably why. For future reference linking to the issues page when there’s over 1.2k issues is unhelpful to the reader, you’re better off putting that list into your blog post, or just pick one that’s the most useful like https://github.com/microsoft/WSL/issues/7492 https://github.com/microsoft/WSL/issues/7492. I doubt the reader is going to trawl for every single issue to find the ones you’re talking about. It’s like saying “Google it yourself”.
      - abdusco 5y ago
        When I had linked it in August 2020, it mostly had results for issues related to localhost forwarding, so it made sense at the time. But linking a live search wasn't the best choice, I agree. I think linking to a specific issue is more useful, like you say. I'll update the post. > It’s like saying “Google it yourself”. Funny enough, almost all traffic is from organic searches :)
- NelsonMinar 5y ago
  Yeah this is an annoying bug. It seems related to resuming from sleep. For WSL 2 one workaround is to just restart WSL; you're effectively rebooting the VM.

abdusco 5y ago

I occasionally run into an issue that breaks localhost port forwarding. I can access the service that's running inside WSL2 via its actual IP (172.#.#.#) when 127.0.0.1 breaks. But that IP address changes every time WSL instance restarts. I've had to set up a scheduled task[0] to update an entry in my hosts file every time WSL is assigned a new IP address, which works well enough. [0]: https://abdus.dev/posts/fixing-wsl2-localhost-access-issue/ https://abdus.dev/posts/fixing-wsl2-localhost-access-issue/

jayflux 5y ago
Excuse my ignorance here but why are you using its actual IP instead of just localhost or 127.0.0.1? When starting up a local server inside of WSL I’ve never needed to do that (unless it needs to be accessed somewhere else in the network) I know the blog post says localhost redirection “often fails” but that’s just never been the case for me, and the citation it uses is just a link to the WSL issues page rather than a specific issue.
- abdusco 5y ago
  Localhost mostly works, and I use localhost when it does work. But when it fails (once a week or so, and this keeps happening on 3 different machines running the latest/a recent Insider build), usually after the PC wakes up from sleep, I have to restart the PC to access via localhost again, which is undesirable for me because I have to spend 10 min restoring all apps & windows back to how they were. Or I can use the IP address directly and map it to a friendly hostname, in my case `wsl` and keep working. This is done behind the scenes with a scheduled task, so when I see `localhost:PORT` doesn't work, I just retry it with `wsl:PORT`. The reason I haven't linked to a specific issue is that there's just so many [*], and localhost sharing is still buggy and hasn't been fixed even after 2 years. [0]: https://github.com/microsoft/WSL/issues/5298 https://github.com/microsoft/WSL/issues/5298 [1]: https://github.com/microsoft/WSL/issues/7492 https://github.com/microsoft/WSL/issues/7492 [2]: https://github.com/microsoft/WSL/issues/6725 https://github.com/microsoft/WSL/issues/6725 [3]: https://github.com/microsoft/WSL/issues/4885 https://github.com/microsoft/WSL/issues/4885 [4]: https://github.com/microsoft/WSL/issues/5439 https://github.com/microsoft/WSL/issues/5439 and many more.
  - jayflux 5y ago
    Fair enough, hopefully that gets fixed, my machine doesn’t go to sleep that often so maybe that’s why I haven’t been affected. My servers are not usually long-running, I only use them when developing so that’s probably why. For future reference linking to the issues page when there’s over 1.2k issues is unhelpful to the reader, you’re better off putting that list into your blog post, or just pick one that’s the most useful like https://github.com/microsoft/WSL/issues/7492 https://github.com/microsoft/WSL/issues/7492. I doubt the reader is going to trawl for every single issue to find the ones you’re talking about. It’s like saying “Google it yourself”.
    - abdusco 5y ago
      When I had linked it in August 2020, it mostly had results for issues related to localhost forwarding, so it made sense at the time. But linking a live search wasn't the best choice, I agree. I think linking to a specific issue is more useful, like you say. I'll update the post. > It’s like saying “Google it yourself”. Funny enough, almost all traffic is from organic searches :)
NelsonMinar 5y ago
Yeah this is an annoying bug. It seems related to resuming from sleep. For WSL 2 one workaround is to just restart WSL; you're effectively rebooting the VM.