Connecting to X Server in wsl-integration.sh causes very long startup times in WSL

[craigloewen-msft]

Background Information:

• Build: 19033
• WSL: Ubuntu 18.04
• Version: ??

Describe the bug
There are reports that the latest update in WSLUtilities causes a very long startup time in WSL2.

Please see the attached threads for descriptions and reproductions:
microsoft/WSL#4737
microsoft/WSL#4725

To Reproduce
See attached threads.

Expected behavior
Startup time in WSL should be fast.

Additional context
This seems to be related to checking for an X server and for audio:
microsoft/WSL#4737 (comment)

Thanks!

[phealy]

I concur - as the code sets DISPLAY to the remote IP of the Windows side then runs xvinfo, it will cause timeouts if the Windows Firewall is in the default drop mode when xvinfo tries to connect.

It doesn't happen by default because x11-utilities isn't installed by default, so xvinfo isn't there. However, the Visual Studio Code Live Share integration installs it if you're running WSL-Remote, and other packages may as well.

[rbalint]

This is tracked in https://bugs.launchpad.net/ubuntu/+source/wslu/+bug/1855520 is is already fixed in Ubuntu development release and we are about to revert the package to a known-good state, then roll out an improved, much faster detection method.

[rbalint]

The change causing the long delay on WSL2 has been reverted in Ubuntu yesterday thus it can be fixed now with apt update ; apt upgrade.
There is also an improved fix adding all detection with caching the results in the -proposed pocket.
The https://bugs.launchpad.net/ubuntu/+source/wslu/+bug/1855520 bug includes information on how to get that fix. Feedback is appreciated.

[phealy]

I pulled the change earlier today and definitely see an improvement in startup speed. It looks like it'll require a little more work for remote X11, but I would expect that as it's a much less common use case. Thanks!

[rbalint]

@phealy The idea is that for remote X11 you can populate the cache before the detection takes place.

[crramirez]

Hello @craigloewen-msft

This is just a sample of what could happen if WSL 2 is released with its network being "Unidentified Network" type instead of a "Trusted" one or at least "Private." (microsoft/WSL#4139)

I understand that Graphics are not supported in WSL. Still, I can't imagine the number of complaints in Pengwin and bad reviews when graphics won't work without allowing the Xserver through the firewall as a "Public" access.

Maybe it is tough to tell the firewall to trust connections from the WSL network by default, but I think it should have a high priority in the roadmap.

Regards,
Carlos

[craigloewen-msft]

Hi @crramirez , that's a great point! We're looking into how to better address this, you're right it is a tough problem but it's also a priority for us to improve our networking story. I will be sure to post any updates to the command line blog or my Twitter as they become available :)

[rbalint]

The Ubuntu packages are fixed now, IMO this issue can be closed. The improved detection just landed in all releases, thus the detection has timeout and the results are also cached until the whole WSL instance is restarted.

[lindhe]

When was this fix introduced? I'm on wslu 3.2.3-0ubuntu3 and I am experiencing similar issues.