[WSL2] [Interop] Keep a single shared /run/WSL/* socket

[paulstelian97]

Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.

If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.

Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to secure@microsoft.com. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump".\

See our contributing instructions for assistance.

Please fill out the below information:

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.19041.172]

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

Launch a new console of a WSL2 distro (either in Windows Terminal, wsl.exe directly or anything else). Then launch either tmux or gnome-terminal. Then close the original console. If I return to the tmux session and try to run a Windows executable, or if I attempt this in gnome-terminal, I get the following error:
<3>init: (11770) ERROR: UtilConnectToInteropServer:300: connect failed 2

This is because the $WSL_INTEROP variable points to a socket which was deleted (when the original terminal was closed)

• What's wrong / what should be happening instead:

Be able to use Interop even in that situation.

• Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here).
  The only mildly relevant line sums up as:
  connect(fd, {AF_UNIX, sun_path="/run/WSL/11067_interop"}, 110) = -1 ENOENT.

• For WSL launch issues, please collect detailed logs.

[therealkenc]

Alright, gleaning the repro, you're in a state like this:

You can see /init listening with lsof. Here the client's /init parent is 173:

As a work-around, you can set the $WSL_INTEROP variable manually.

Perhaps the binfmt interpreter instance of /init could walk up the process tree itself, automating the aformentioned. Eliminate $WSL_INTEROP. [Just spitballing.]

[paulstelian97]

Workaround works, of course, but unless there is a way I can somehow automate it it doesn't matter.

[lvlts]

I have this function in my .zshrc, and I call it on every shell init:

fix_wsl2_interop() {
    for i in $(pstree -np -s $$ | grep -o -E '[0-9]+'); do
        if [[ -e "/run/WSL/${i}_interop" ]]; then
            export WSL_INTEROP=/run/WSL/${i}_interop
        fi
    done
}

So far, so good, it works all the time.

Edit: fixed the regex to include 0 as @zakandrewking pointed out.

[zakandrewking]

thanks @lvlts, this helps me. I'd suggest a small change: grep -o -E '[0-9]+'

[paulstelian97]

I have this function in my .zshrc, and I call it on every shell init:

fix_wsl2_interop() {
    for i in $(pstree -np -s $$ | grep -o -E '[0-9]+'); do
        if [[ -e "/run/WSL/${i}_interop" ]]; then
            export WSL_INTEROP=/run/WSL/${i}_interop
        fi
    done
}

So far, so good, it works all the time.

Edit: fixed the regex to include 0 as @zakandrewking pointed out.

Stole that, added in my own .bashrc. I'll just call it manually if I see issues.

[str4d]

If anyone is arriving here and needs a similar function for nushell (like I did):

alias fix-wsl2-interop --save [] {
  echo $nu.env | insert WSL_INTEROP $(
    pstree -np -s | grep -o -E '[0-9]+' | lines | each {
      build-string /run/WSL/ $it _interop
    } | split column "|" path | insert exists {
      get path | path exists
    } | where $it.exists | get path
  ) | config set_into env
}

[elucidsoft]

This is freaking odd, I had a previous build with WSL 2 exact same source code, everything the same. I reinstalled windows and recreated the setup, and encountered this issue without explanation. The same setup as before, so what made this happen this time vs. last time? I have no idea, as I literally set both environments up following the exact same procedures.

[paulstelian97]

This is freaking odd, I had a previous build with WSL 2 exact same source code, everything the same. I reinstalled windows and recreated the setup, and encountered this issue without explanation. The same setup as before, so what made this happen this time vs. last time? I have no idea, as I literally set both environments up following the exact same procedures.

@elucidsoft Are you using stuff like Gnome Terminal or other GUI apps? The /run/WSL/* sockets remain valid as long as the wsl.exe or bash.exe (or ubuntu.exe etc) commands that you manually call remain valid. I encounter the issue whenever using gnome-terminal since that one allows the original normal or wt.exe terminal executable to close and invalidate the socket.

[elucidsoft]

I am using VSCode, but what's odd this never happened to me once in my previous setup which should have been identical.

[fsackur]

...and for any powershellers, a similar function for pwsh:

function Reset-WslInterop
{
    param ($ProcessId = $PID)

    if (Test-Path /run/WSL/$ProcessId`_interop)
    {
        $env:WSL_INTEROP="/run/WSL/$ProcessId`_interop"
        return
    }

    Reset-WslInterop (Get-Process -Id $ProcessId).Parent.Id
}