WSL2 systemd RemoteApp connection invalid / WSLg apps not working

[xcorp]

Version

Microsoft Windows [Version 10.0.22000.978]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.15.62.1-microsoft-standard-WSL2

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

Installed pre-release https://github.com/microsoft/WSL/releases/tag/0.67.6
Added
[boot] systemd=true
to /etc/wsl.conf

Expected Behavior

Working WSLg apps with no alert windows.

Actual Behavior

When I start WSL I get an alert windows with the text "The connection information for this resource is invalid"

Clicking OK closes the windows for a second before it appears again.

Starting a second fresh WSL instance of another distro gives the same error, even though systemd=true is not set

Trying to start an app with WSLg, for example firefox doesn't work.
On the first WSL instance I get the following

$ firefox
Unable to init server: Could not connect: Connection refused
Error: cannot open display: :0

$ DISPLAY=:0 firefox
Unable to init server: Could not connect: Connection refused
Error: cannot open display: :0

Trying the same on the second instance firefox runs, but a window for it is never presented.

$ firefox
Error: no DISPLAY environment variable specified

$ DISPLAY=:0 firefox
[GFX1-]: glxtest: libEGL missing
[2022-09-26T07:25:12Z ERROR glean_core::metrics::ping] Invalid reason code startup for ping newtab
Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs
^CExiting due to channel error.

Setting systemd to false on the first instance and running wsl --shutdown restores all WSLg functionality and no alert windows show when starting WSL

Diagnostic Logs

No response

[roblatham00]

I'm seeing different symptoms, but also graphics related so I'll add here (happy to open a new issue if that makes more sense).

When I enable systemd by editing /etc/wsl.conf some graphical applications are unable to load.

• xload: "Error: cannot open display: :0"
• gvim: "Error: cannot open display: :0"

However, some applications like the 'eog' image viewer and the 'evolution ' mail reader start up just fine.

Once I turn off systemd, xload and gvim work just fine.

[cerebrate]

@roblatham00 Your specific problem is probably that the X server socket is missing. Can you ls /tmp/.X11-unix/X0?

If not, you have the issue where systemd, on starting, clears out /tmp and gets this socket on the way. Put this file in /lib/tmpfiles.d and restart WSL to prevent this.

[benhillis]

@cerebrate - is there a way to update that symlink to be a bind mount instead?

[cerebrate]

@benhillis Not quite as easily as leveraging systemd-tmpfiles, since it doesn't have an option to create those. You'd have to have it create the mount point and then create a new systemd unit to run after systemd-tmpfiles to do the mounting.

[cerebrate]

@benhillis ...and since I am apparently constitutionally unable to not build prototypes of things:

https://gist.github.com/cerebrate/5cc6b2d6b9a42812ced020ea3e59b059

does exactly that. 😁

[c4artisan]

@benhillis ...and since I am apparently constitutionally unable to not build prototypes of things:

https://gist.github.com/cerebrate/5cc6b2d6b9a42812ced020ea3e59b059

does exactly that. 😁

i did that and it didn't do anything. also broke the gnome applications

[cerebrate]

@c4artisan Let's keep that issue all in one place at #8899 .

[NotTheDr01ds]

@benhillis I've been meaning to post this as a separate issue for a while, but if you change the new bind mount (#8411 - good change by-the-way) to be read-only, I think (from my testing) it will prevent this from happening. It looks like the Systemd-enablement changes are designed to inject some new tmpfiles.d files that don't overwrite the socket, but that doesn't seem to be 100% reliable.

According to the Arch Systemd-nspawn documentation, which seems to be closely related to the WSL implementation, at one point at least this was required:

Note: Since systemd version 235, /tmp/.X11-unix contents have to be bind-mounted as read-only, otherwise they will disappear from the filesystem. The read-only mount flag does not prevent using connect() syscall on the socket. If you binded also /run/user/1000 then you might want to explicitly bind /run/user/1000/bus as read-only to protect the dbus socket from being deleted.

And a link directly to the Poettering comment (does he really work for MS now or is that just a rumor?) on the topic.

While there's some question as to whether or not this is still the case for Systemd-nspawn, I tried it soon after the bind-mount change, and (although I don't use Systemd all that often), it seemed to prevent systemd-tmpfiles from overwriting the WSLg socket.

[cerebrate]

@NotTheDr01ds

I wrote up a whole discussion of the topic here, but to sum up the relevant bit, on my system the /tmp/.X11-unix folder never appeared despite those /dev/null-ed tmpfiles.d files, and I'm pretty sure it's because systemd is mounting a fresh new tmpfs over /tmp as part of its boot process well before we get to that point.

[cerebrate]

@benhillis

Still got this issue and can confirm it's because tmp.mount is mounting a fresh tmpfs over the top of tmp . Unmounting it manually lets me see the /tmp/.X11-unix/X0 WSLg bind-mounted there, but then I've also got an on-disk /tmp, so it's easier to just bind-mount it again myself.

[cerebrate]

Although whatever's doing the mounting of /tmp/.X11-unix initially seems to have changed, as now it's causing my poor .mount unit to have conniptions. I've had to use a .service unit to do the re-bind-mounting and move it later in the systemd startup process (before multi-user.target instead of before sysinit.target).

[benhillis]

@cerebrate - I'm a bit confused what's happening, we're not waiting for systemd to finish booting before setting up the /tmp/.X11-unix directory. It seems to be working locally for me.

[benhillis]

Ah I might have an idea of what this is, might you be running elevated / non elevated wsl.exe processes together?

[cerebrate]

@benhillis

Oh! This is all a bit speculative, if you'll forgive me, but it seems to me that this all makes sense if it's a race condition.

If I'm right and your setting up of /tmp/.X11-unix happens in parallel to the systemd startup, then depending on how fast systemd startup runs, either systemd will mount /tmp first, then the setup happens, and you end up with a working system with the /tmp/.X11-unix mount visible; or /tmp/.X11-unix will be setup first, then systemd will automatically mount /tmp on top of it, and you end up in my scenario in which /tmp/.X11-unix is empty because the mount point is hidden.

(The chronological ordering of /proc/mounts supports this, because mine - gist here, as it's long - clearly shows the second ordering of the mounts hiding the mount point. I would guess that of your working system would show the opposite ordering.)

That would explain how some people get working systems and some don't, and how in the non-working case, unmounting the tmpfs /tmp reveals the /tmp/.X11-unix bind mount set up "underneath" it, in the underlying mount point directory.

Plausible?

[xcorp]

Just want to say that I launched a new instance and moved over what I needed from the old one. No issues so far with the new one.
Feel free to close issue.

[cerebrate]

I'd like to request we keep this issue open until the underlying problem's resolved, just to avoid having to create a new issue to track it.

[cerebrate]

@benhillis Sorry to say, I get the same mount ordering problem under 0.70.8; looks like the fix for #9038 didn't fix it for me.

[ThexXTURBOXx]

I am using python3 through WSL 2 in PyCharm. I also get the same error (although in German) whenever PyCharm is running. When clicking on "OK" or closing the window, a new one opens.
This is really annoying and I cannot seem to find any solution other than reinstalling my WSL. Is there any other solution yet?

[wojtekow]

Same here, though the message is in Polish 😂

And it is definitely related to systemctl as it only happens when I spawn wsl with either genie:

wsl.exe -d Ubuntu-20.04 genie -s

or when enabling systemd in /etc/wsl.conf:

[boot]
systemd=true

[4wk-]

Hello.

Same here: infinite error windows "RemoteApp", after waking up PC from sleep (I had multiple Debian launched)
wsl genie -s

wsl -l -v
  NAME      STATE           VERSION
* Debian    Running         2
  Ubuntu    Stopped         2

NB: AFAIK, I never tried nor wanted to use any WSLg app

[romanofski]

I noticed that I get heaps of these windows with an open Explorer. Close the explorer and you can close the dialogs as well. I don't have information on the internals on what's going on here, but it's almost reliably reproducible with an open explorer window.

[ThexXTURBOXx]

@romanofski Not entirely true. The bug is reproducible when the process is open that uses WSL. In my case, this is not the explorer, but rather PyCharm. As soon as I close PyCharm, I can close the last dialog and no other one opens. The explorer was not open at that point.

[4wk-]

Hey again. For the record, launching wsl with genie is now outdated, and I think this is related to this popin error.

Fix: I completely uninstalled wsl, reinstalled it, then enabled systemD support the right way (without genie).
https://gist.github.com/4wk-/889b26043f519259ab60386ca13ba91b
@wojtekow RemoteApp error is gone after this clean uninstall then reinstall.

Hope it helps someone!

[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!