search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.51k stars 822 forks source link

User sessions started from non-wsl.exe sources (such as systemd services) don't have WSL_INTEROP #8846

Open cerebrate opened 2 years ago

cerebrate commented 2 years ago

Version

Microsoft Windows [Version 10.0.22000.856]

WSL Version

Kernel Version

5.15.62.1-20220921-1-microsoft-custom-WSL2+

Distro Version

Debian bookworm/sid

Other Software

No response

Repro Steps

  1. Ensure that your WSL distro has systemd-machined installed and enabled.
  2. Start a WSL session.
  3. At this point, in the shell created by wsl.exe, echo $WSL_INTEROP will return a value, such as /run/WSL/136_interop
  4. Use sudo machinectl shell <username>@.host to enter a user session under systemd.

(This is used as a workaround to get a systemd user session created; see #8842 . But the same issue applies to any user session created under systemd/by non-wsl.exe means, including ssh, etc.)

  1. At this point, echo $WSL_INTEROP will show nothing.
  2. Attempt to run a Windows application, such as /mnt/c/Windows/notepad.exe

Expected Behavior

The Windows application should run as normal for interop.

Actual Behavior

The Windows application fails to run and exit code 1 is returned:

❯ /mnt/c/Windows/notepad.exe
[1]    31535 exit 1     /mnt/c/Windows/notepad.exe

Diagnostic Logs

No response

cerebrate commented 2 years ago

The failure in this case is obviously from the lack of WSL_INTEROP in systemd-started sessions. It can be worked around, if you have a long-running WSL session, by pushing the WSL_INTEROP environment variable for that session into the system environment block using

systemctl import-environment WSL_INTEROP

at which point it is inherited by all systemd services and sessions.

(The problem with that is that while it was a viable solution for genie, because the init above genie would always be around for as long as systemd would be, there isn't such a guaranteed-present-as-long-as-systemd init around under the native systemd support - and so this workaround relies on keeping one particular WSL session open perpetually to provide the socket behind WSL_INTEROP.)

benhillis commented 2 years ago

Thanks - I agree launching Windows processes from things launched from systemd would be a good enhancement and shouldn't be too bad to implement. I'll see what I can do.

jelical commented 2 years ago

Voting for this enhancement - I am specifically prefer to use my XWin instead of wslg and till now i enabled it from systemd user unit. Unfortunately it stopped working when I moved to builtin systemd

cerebrate commented 2 years ago

Same problem in 68.2, I'm afraid. Both, in fact - no WSL_INTEROP in the systemd or systemd user session environment, and the binfmt is lost.

qcasey commented 11 months ago

The solutions provided in #5065 are a workaround for my own systemd services