interop: slow startup times if executable is placed on linux filesystem

[tobiaskohlbau]

Version

Microsoft Windows [Version 10.0.22483.1000]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.60.1-microsoft-standard-WSL2

Distro Version

Ubuntu 20.04

Other Software

wsl2-ssh-pageant

Repro Steps

Placing an windows executable on linux side and launching it like for e.g. wsl2-ssh-pageant results in a significant time delay. We've had multiple people report this issue over at BlackReloaded/wsl2-ssh-pageant#24. It looks/behaves pretty similar to #7521 which wasn't able to launch the executable at all. It's important that these users report the issue with Windows 11 without the store version.

Expected Behavior

The speed should be the same not noticing a difference if the file is placed on windows filesystem or linux filesystem.

Actual Behavior

@kaeltis comment got me experimenting and uncovered the simplest of solutions: Copy wsl2-ssh-pageant.exe to your Windows user home directory and run it from there. Now the response time is blazing fast again - under 200ms.

Diagnostic Logs

No response

[tobiaskohlbau]

Pinging @benhillis as he identified the issue at #7521. I could assume that a similar change introduced by the store version was introduced earlier on in the windows 11 development cycle.

Edit: It's also important that I for myself where never able to reproduce this issue on my machine. Therefore we're still searching for the commonality between the users reporting this to us.

[benhillis]

@tobiaskohlbau - do you have an indication of how much slower it is? I'd expect it to be a bit slower because this is going over the 9p server, but not a ton longer.

I cannot reproduce this either, if your users can help narrow this down that would help make it more actionable.

[tobiaskohlbau]

I've created a simple app which only finds the underlying pageant window:

package main

import (
        "fmt"
        "syscall"

        "github.com/lxn/win"
)

func main() {
        hwnd := win.FindWindow(syscall.StringToUTF16Ptr("Pageant"), syscall.StringToUTF16Ptr("Pageant"))
        fmt.Println(hwnd)
}

One user executed it on it's windows path:

vibs@J-KINSMAN-2019:/mnt/c/Users/kinsman.PASCALL/downloads $ time ./pageant-check.exe
66862

real    0m1.502s

whereas put on the linux filesytem:

vibs@J-KINSMAN-2021:~$ time ./pageant-check.exe
525766

real    0m22.944s
user    0m0.001s
sys     0m0.000s

So we're roughly speaking of 23s vs 1.5s.

Edit:

I've asked the users reporting that issue to describe their setup in this issue.

[jliedy]

Windows 11 Pro v21H2
Build: 22000.194
Feature Experience Pack 1000.22000.194.0

WSL Update v5.10.43
WSLg Preview v1.026

At one point, I had no issues running this on an Ubuntu install that was done months ago, even after patching to Win 11 and WSLg. Was having issues with resolv.conf being a jerk, so I wiped the install and started with a fresh install. That was where I started running into the issues with the wsl2-ssh-pageant check. This included runaway processes that would soak up the cpu until I force-killed WSL altogether.

Let me know if there's anything more specific I could provide.

[VibroAxe]

Windows 11 Pro v21H2
Build: 22000.194
Feature Experience Pack 1000.22000.194.0

WSL Kernel v5.10.43.3

I believe I've only encountered this on a fresh install of windows 11 / wsl but it's replicable across two different laptops (Intel and Ryzen)

@tobiaskohlbau out of interest, were you able to replicate on a new distro install?

[ophers]

I'm experiencing this also. I'm running Windows 11 Enterprise upgraded from Windows 10 Enterprise.

>ver
Microsoft Windows [Version 10.0.22000.282]

>wsl --status
Default Distribution: Ubuntu-20.04
Default Version: 2

Windows Subsystem for Linux was last updated on 07/10/2021
WSL automatic updates are on.

Kernel version: 5.10.60.1

>docker --version
Docker version 20.10.8, build 3967b7d

[Ahuge]

I have the same issue

Windows 11 Pro v21H2
Build: 22000.348
Windows Feature Experience Pack 1000.22000.348.0

WSL version: 0.50.2.0
Kernel version: 5.10.74.3
WSLg version: 1.0.29
Windows version: 10.0.22000.348

I previously was running the wsl-ssh-pageant software from the Linux VM when using WSL in windows 10.
I ran a full wipe and reinstall to get to Windows 11 and installed WSL from the Windows Store. I then started having this same issue and moving wsl-ssh-pageant to the windows side fixes it.

Let me know if there's anything more specific I could provide.

[JeGr]

I still see the same issue and got here luckily by finding out about this from BlackReloaded/wsl2-ssh-pageant#29

Windows 11 Pro v22/H2
Build: 22621.1702

WSL: 1.2.5.0
Kernel: 5.15.90.1
WSLg: 1.0.51
Windows-Version: 10.0.22621.1702

I was copying over a WSL2 instance from my company laptop with Win10Pro before switching over to a new one and a workstation both with Win11 Pro. Worked OK but the SSH times were bugging me as they needed around 5-6s until my paegent-style agent popped up prompting for my key password.

Switching the location for wsl2-ssh-pageant.exe from the old documented $HOME/.ssh/ location to the mounted NTFS filesystem reduced that lookup time from ~5.2s to ~0.25s

Happy to supply more information to get that sorted out.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!