-
Notifications
You must be signed in to change notification settings - Fork 822
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WSL2] [Interop] Keep a single shared /run/WSL/* socket #5065
Comments
Alright, gleaning the repro, you're in a state like this: You can see As a work-around, you can set the Perhaps the binfmt interpreter instance of |
Workaround works, of course, but unless there is a way I can somehow automate it it doesn't matter. |
I have this function in my
So far, so good, it works all the time. Edit: fixed the regex to include |
thanks @lvlts, this helps me. I'd suggest a small change: |
Stole that, added in my own .bashrc. I'll just call it manually if I see issues. |
If anyone is arriving here and needs a similar function for nushell (like I did):
|
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. |
I am using VSCode, but what's odd this never happened to me once in my previous setup which should have been identical. |
...and for any powershellers, a similar function for
|
Yes, I don't use Powershell but I did this in bash script as the solution. |
I've encountered with same error with my WSL2, when was trying to run
But later I just run it as root and that resovled the trouble |
@lyf2000 Is there any way this could run without the sudo? |
|
So I get this issue repeatedly because I like to use the gnome-terminal instead of Windows Terminal. Here's the steps to reproduce:
NOTE: that it works and prints out the contents of the Windows Environment Variable USERPROFILE.Also note the contents of the WSL_INTEROP bash environment variable points to /var/run/NNNN_interop or something like that
|
The fact that the socket is per-tty rather than, say, per-Windows session or something, is annoying. I would have preferred to always run Gnome Terminal and launch new terminals from that one always. |
I'll leave my version for # .config/fish/conf.d/wsl.fish
function fix_wsl2_interop
for i in (pstree -np -s $fish_pid | grep -o -E '[0-9]+')
if test -e "/run/WSL/"$i"_interop"
set -x WSL_INTEROP "/run/WSL/"$i"_interop"
end
end
end
fix_wsl2_interop |
Ok, the solutions listed here doesn't work for me.. |
You should see if anything at all exists in /run/WSL/. If not, then it's because there's simply no open native terminal. |
I've done it with adding this to my .zshenv
No idea how robust this is going to be, but the oldest socket seems to be the one for me. |
I think this would work.. Because if you think about it, whenever you open a new instance a new file is generated and it will be the file we need to assign to the environment variable. Thanks. Edit: Just realized, I think you shouldn't reverse order. Because |
On my machine, the oldest one is the one that always seems to work. It's all the new ones that are created, per shell, that don't. Perhaps we have different issues that manifest the same? |
Well, using the oldest also works. Although I'm using this for |
Yeah, as I mentioned, no idea how robust this will be, it's just a work around until we can get a real one in WSL (fingers crossed). |
I think any of the sockets work, so you just need a heuristic to select the one that will take the longest to be closed. Could be oldest, could be newest, could be any of the others. When you close one of the native terminals (wt, bash.exe, ubuntu.exe etc) the corresponding socket will be both closed and deleted from that path. |
In my specific case, only the lowest numbered works. |
I wanted a solution that would work automatically in existing shells, not just new ones (or by manually executing a fix). Others may want this solution too. Running the function from above within a PROMPT_COMMAND means I've also optimised the function a little to short circuit the run if possible and avoid the extra proccess call ( prompt_fix_wsl() {
# return early if WSL is missing or already working
[[ -n "$WSL_INTEROP" ]] || return
! [[ -e "$WSL_INTEROP" ]] || return
local pid pids
# parse pstree output in to pids array
IFS='-()'
# shellcheck disable=SC2207
pids=($(pstree --numeric-sort --show-pids --show-parents $$))
unset IFS
for pid in "${pids[@]}"; do
[[ "$pid" =~ [0-9]+ ]] || continue
[[ -e "/run/WSL/${pid}_interop" ]] || continue
export "WSL_INTEROP=/run/WSL/${pid}_interop"
# stop looking for sockets
return
done
} Setting it up like so: function my_prompt_command {
# .... my existing prompt command that's probably too long to justify the above optimisation ...
prompt_fix_wsl
}
PROMPT_COMMAND=my_prompt_command
|
All of these workarounds assume you don't need to keep the original interop socket open (because it's in use). When using something like wsl-vpnkit to allow WSL2 networking under a VPN it launches a persistent windows process, but that process gets terminated when the shell that started it is closed. While it's possible to detect and remediate the closure it would be much better if there was just a single socket instead of one per-tty. |
all of this solutions doesn't work for https://github.com/shayne/wsl2-hacks, as terminal pid isn't accessible anymore I come up with this solution :
|
Thanks, it works like a charm. |
This works for me. |
that breaks on wsl2 |
Fix by search lowest ancestor of tmux: client that is init #!/usr/bin/bash
fix_wsl_interop_tmux() {
ancestors_of_tmux_client() {
pstree --show-pids | fgrep 'tmux: client'; }
get_pid_of_lowest_ancestor_init() {
select_numbers() {
grep -oP '\d+'; }
select_line_-3(){
tail -n3 | head -n1; }
select_numbers | select_line_-3
}
REAL_WSL_INTEROP_ID=$(ancestors_of_tmux_client | get_pid_of_lowest_ancestor_init)
sudo ln -s /run/WSL/${REAL_WSL_INTEROP_ID}_interop $WSL_INTEROP
}
fix_wsl_interop_tmux |
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)
Be able to use Interop even in that situation.
Strace of the failing command, if applicable: (If
some_command
is failing, then runstrace -o some_command.strace -f some_command some_args
, and link the contents ofsome_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.
The text was updated successfully, but these errors were encountered: