← Back to team overview

group.of.nepali.translators team mailing list archive

[Bug 1855520] Re: Issue with wsl-integration.sh script causing slow start of Ubuntu shell with WSL2

 

This bug was fixed in the package wslu - 2.3.2-0ubuntu2~18.04.3

---------------
wslu (2.3.2-0ubuntu2~18.04.3) bionic; urgency=medium

  * Detect X and PulseAudio in WSL2, too (LP: #1853343)
  * debian/wsl-integration.sh: Use type instead of which for faster execution.
    Also skip all detection steps when pactl and xvinfo are not installed.
  * debian/wsl-integration.sh: Set timeouts for X and PulseAudio detection.
    This fixes long startup time when detection fails after waiting for long.
    (LP: #1855520)
  * Cache results of detecting X and sound server in
    $HOME/.cache/wslu/integration. (LP: #1855898)
    Reuse results when starting new shells in the same running
    WSL Ubuntu instance.

 -- Balint Reczey <rbalint@xxxxxxxxxx>  Wed, 11 Dec 2019 21:33:12 +0100

** Changed in: wslu (Ubuntu Bionic)
       Status: Fix Committed => Fix Released

** Changed in: wslu (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1855520

Title:
  Issue with wsl-integration.sh script causing slow start of Ubuntu
  shell with WSL2

Status in wslu package in Ubuntu:
  Fix Released
Status in wslu source package in Xenial:
  Fix Released
Status in wslu source package in Bionic:
  Fix Released
Status in wslu source package in Disco:
  Fix Released
Status in wslu source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * Users of Ubuntu on WSL experience long delay in starting the Ubuntu
  shell when the Windows Firewall is turned on.

  [Test Case 1]

   * Install Ubuntu in a WSL2 instance
   * Enable Windows Firewall for Pubic Network
   * (rm -f $HOME/.config/wsl/integration-cache if LP: #1855898 is also fixed)
   * run time . /etc/profile.s/wsl-integration.sh

  [Test Case 2] ()

  (This should be run for (WSL1,WSL2) x (X and PA server running, X and PA server not running) combinations)
   * Install Ubuntu in a WSL2/WSL1 instance
   * Disable Windows Firewall
   * (rm -f $HOME/.config/wsl/integration-cache if LP: #1855898 is also fixed)
   * run:
    $ unset DISPLAY
    $ unset PULSE_SERVER
    $ time . /etc/profile.s/wsl-integration.sh
    $ echo $DISPLAY $PULSE_SERVER

  [Regression Potential]

   * The added timeout may be too low for slow/loaded systems making X/PA server auto detection fail. I've picked the timeout value by testing the successful detection attempts in a KVM VM.
  Pactl commands are consistently slower than xvinfo and WSL1 is consistently slower than WSL2:

     max.   |  WSL1 | WSL2
  ----------+-------+------
  pactl info| ~0.5s |~0.1s
  ----------+-------+------
  xvinfo    | ~0.3s |~0.07s

  The CPU used in testing: i5-7300U CPU @ 2.60GHz

  
  [Original Bug Text]

  $lsb_release -rd
  Description:    Ubuntu 18.04.3 LTS
  Release:        18.04

  Today I ran an apt update of my WSL2 Ubuntu 18.04.2 LTS installation
  on Windows 10 insider build 19037.1. I then noticed when I launched
  the WSL2 Ubuntu shell that it took about 38 seconds to get a shell
  prompt. This was not an issue until after I did the update. After some
  troubleshooting I found out this delay was because of wsl-
  integration.sh, that the wslu update appears to have added. The
  following two commands:

  env DISPLAY=${WSL_HOST}:0 xvinfo
  env PULSE_SERVER=tcp:${WSL_HOST} pactl info

  in this script are both timing out on my computer. Because both
  commands are timing out, that accounted for the 38 seconds it took to
  get a shell prompt.

  In my case, my WSL_HOST IP was 172.24.144.1 and so I ran these two
  commands:

  env DISPLAY=172.24.144.1:0 xvinfo
  env PULSE_SERVER=tcp:172.24.144.1 pactl info

  and sure enough it took a combined time of about 38 seconds for them
  to timeout. This is only an issue when running Ubuntu in WSL2, not
  WSL1. WSL1 launches fine. In the case of the my WSL1 instance, the
  WSL_HOST appears to be null when running your script, so it assigns
  localhost to WSL_HOST, and both of these commands timeout without
  delay.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wslu/+bug/1855520/+subscriptions