Cannot launch gui apps with 2.0.12

[dciarniello]

Windows Version

11

WSL Version

2.0.12

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

No response

Distro Version

Fedora

Other Software

No response

Repro Steps

I usually launch GUI apps from the windows start menu but after upgrading to 2.0.12, the apps wouldn't start. wsl --list --running showed the distro running for a few seconds and then it shutdown. I am able to start WSL from the command line but when I try to launch a gui app such as konsole, I get this error:

qt.qpa.xcb: could not connect to display :0

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.

This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Aborted (core dump)

There were no issues with 2.0.11

Expected Behavior

GUI apps start as usual

Actual Behavior

GUI apps cannot be launched

Diagnostic Logs

No response

[sad-poet]

Have had a similar problem with GUI applications after updating to WSL 2.0.12.0:

$ xclock
Error: Can't open display: :0

$ wsl.exe --version
WSL version: 2.0.12.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3570

Fixed by running the following commands:

sudo umount /tmp/.X11-unix
sudo rm -rf /tmp/.X11-unix
sudo ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

and GUI applications were working again.

Not sure if this survives a WSL virtual machine reboot.

This solution was found here: #558 (comment)

[dciarniello]

Unfortunately, that didn't work. :-(

[mvimercati]

I confirm also here same behaviour.
Temporarily fixed with this command as root (Does not survive at reboot):
rm -rf /tmp/.X11-unix && ln -s /mnt/wslg/.X11-unix /tmp/

[dciarniello]

Ok, I see. The "does not survive reboot" did not click when I first tried this.
Hopefully a fix comes soon as that is somewhat inconvenient to have to do so I will stick with 2.0.9 for now.

Thanks

[hajeka]

Disabling systemd in /etc/wsl.conf is a permanent workaround, but not an option for me

[dciarniello]

This issue was moved over from WSL but I'm wonder if that was appropriate. If I'm not mistaken, the WSLg version has not changed since March so it looks like this issue was introduced in WSL not WSLg. I'm wondering if microsoft/WSL#10818 is the cause as that looks related.

[fknittel]

Does your system have a /run/tmpfiles.d/x11.conf file? If not, does the /tmp/.X11-unix folder/symlink get fixed if you create your own empty /etc/tmpfiles.d/x11.conf file? (Reboot of wsl required)

[rahulshamkuwar]

Not sure if this survives a WSL virtual machine reboot.

I'm using Arch Linux and have the same issue. I created a fix for this that runs those commands as a systemd service (iirc Fedora comes with systemd as well, but regardless of your distro, as long as it uses systemd, it should work). This means that the service will run those commands on boot.

This is under the assumption that running those commands does not lead to any unforeseen side effects (I haven't seen any so far, from my understanding, those commands are fine to run...).

1. Creating the systemd service file

Start by creating a systemd service file at the following location, /etc/systemd/system/. You can name the service file whatever you like, however, keep in mind that the name of the file must have a suffix of service. Then open the file with your preferred text editor. In my case, I ran the following:

sudo nano /etc/systemd/system/x11-symlink.service

Note: nano creates a file if it doesn't exist by default, if your text editor doesn't do this, you'll need to create the file first with touch.

2. Write the scripts for the service

To preface this part, I personally never had anything mounted on /tmp/.X11-unix, so running the umount command for that would result in an error. I would recommend running this command on your terminal just to see if you actually need it or not.

In the service file, add the following contents to it:

[Unit]
Description=Setup X11 Symlink

[Service]
Type=oneshot
ExecStartPre=/bin/umount /tmp/.X11-unix
ExecStartPre=/bin/rm -rf /tmp/.X11-unix
ExecStart=/bin/ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

[Install]
WantedBy=multi-user.target

If you do not need to run the umount command, you should remove it, otherwise the service will fail and exit.

Now you can save and exit the file.

3. Enable the service

To enable the service, we first need to reload systemd to recognize the new service:

sudo systemctl daemon-reload

Then we can enable the service on boot:

sudo systemctl enable x11-symlink.service

Note: the name of the service would be the name of the file you created earlier, make sure this matches.

At this point, you can restart WSL and verify if the service worked by running:

sudo systemctl status x11-symlink.service

If you want to manually start the service without having to restart WSL, you can run the following directly:

sudo systemctl start x11-symlink.service

To verify that it did work, run ls /tmp/.X11-unix and you should see something like X0 or X1, indicating your display.

Hope this helps, lmk if you need extra clarification.

[dciarniello]

Does your system have a /run/tmpfiles.d/x11.conf file? If not, does the /tmp/.X11-unix folder/symlink get fixed if you create your own empty /etc/tmpfiles.d/x11.conf file? (Reboot of wsl required)

Yes, it does. Interestingly, the file has a note:

This file is generated by WSL to prevent systemd-tmpfiles from removing /tmp/.X11-unix during boot.

I'm still running 2.0.9 so I don't know if it's still there in later versions.

@rahu, I've thought about doing something similar though I hadn't considered doing it with systemd.

What's interesting is that it seems that the solution to the problem is to do exactly what /run/tmpfiles.d/x11.conf is preventing (sort of, anyway). 😕

[dciarniello]

It seems that with 2.0.15, /run/tmpfiles.d/x11.conf is not created. Maybe that's the root cause of this problem?

[fknittel]

It seems that with 2.0.15, /run/tmpfiles.d/x11.conf is not created. Maybe that's the root cause of this problem?

It definitely feels like the issue you referenced, microsoft/WSL#10818, is related. The fix for that issue, which should disable the above mentioned override file (and possibly further logic) for guiApplications=false actually disabled it unconditionally. It's a shame that wsl part doesn't appear to be open source, so we're forced to poke the Devs through GitHub issues. And if this type of problem goes unnoticed, I get the feeling there's not much automated integration testing involved in the release process.

Does the issue go away on 2.0.15 if you create an empty /etc/tmpfiles.d/x11.conf ? (Which would simply add the override manually instead of thorough wsl)

[dciarniello]

Unfortunately, the issue doesn't go away after adding an empty /etc/tmpfiles.d/x11.conf.

Maybe this issue would get more attention if it were in wsl/issues where I originally opened it. As I mentioned previously, the only changes when this issue appeared were to wsl not wslg.

[KexyBiscuit]

Pretty sure this issue is related to WSL 2.0.12.0 release, maybe it's a regression of the fix of microsoft/WSL#10818, could you please move the issue back to microsoft/WSL? @OneBlue

[KexyBiscuit]

Not fixed in 2.1.1.0 + 1.0.60.

WSL version: 2.1.1.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.26020.1000

[mvimercati]

Not fixed in 2.1.1.0 + 1.0.60.

same here

[dciarniello]

I did try to raise the visibility of this issue by reporting it again in the WSL repo (microsoft/WSL#11064) but the ticket got closed because it didn't have "steps to reproduce" even though I pointed to this ticket. :-(

[dciarniello]

Still there with 2.1.3.0

[biggestsonicfan]

Is there a specific reason that wslg doesn't seem to honor the [automount] root=/path/here/ config in /etc/wsl.conf? I have to recursively delete /tmp/.X11-unix and ln -s the proper wslg mount point every boot to get graphical programs to run.

Specifically, /mnt/ is not the default mount point in SUSE distros. /run/media/[user]/ is, so I override it as that in my SUSE Tumbleweed WSL2. Having the ability to specify a mount point then not honoring it if used seems fairly strange.

[mvimercati]

Same here.
Not clear if this behaviour depends on the installed distro (I use arch) or the problem is for everyone (Seems strange that anyone noticed it).

[dciarniello]

It's not obviously distro-related as I am using Fedora.

[dciarniello]

I'm going to repeat what I said earlier, this issue should be moved back to WSL where I originally created it, given that the problem was introduced with a WSL release that did not include any WSLg changes.

[mvimercati]

It's not obviously distro-related as I am using Fedora.

I just updated another computer from 2.0.9 to 2.1.3, with Ubuntu 22.04... and it works without any workaround!
Here I can see /tmp/.X11-unix/X0 as a file; it is not a link to /mnt/wslg/.X11-unix/X0 (That is present). The two files have the same date/size.

I agree with your last post. I had the same behaviour starting from a specific WSL release that did not include WSLg changes, so it must be something in wsl, or a default configuration changed

[mvimercati]

I just updated another computer from 2.0.9 to 2.1.3, with Ubuntu 22.04... and it works without any workaround! Here I can see /tmp/.X11-unix/X0 as a file; it is not a link to /mnt/wslg/.X11-unix/X0 (That is present). The two files have the same date/size.

Obviously those are 'virtual' file; both path are mounted:
none on /mnt/wslg type tmpfs (rw,relatime)
none on /tmp/.X11-unix type tmpfs (ro,relatime)

I will compare this with the other non-working installation, with Arch

[dciarniello]

Still there with 2.1.4.0

[Parsifa1]

It seems that this problem has not been fixed in the latest version, but the systemctl method is very effective, thank you🙏

[hongy19]

same issue on my side

C:\Users\ehongya>wsl --version
WSL version: 2.0.14.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.4046

[nanjj]

Still there wsl.exe version 2.1.5.0

[gabrielgnsilva]

I had the same issue whenever i open any application, but i found a fix and wanted to share it.

If like me you are using Arch Linux (may work on other distros that have the same problem) i found that the wayland socket isn't symlinked automatically, and combined with @rahulshamkuwar's solution, the problem does not occur anymore.

$ firefox

[656] Wayland Proxy [0x7feae4075450] Error: CheckWaylandDisplay(): Failed to connect to Wayland display '/run/user/1000//wayland-0' error: No such file or directory
Error: we don't have any display, WAYLAND_DISPLAY='wayland-0' DISPLAY=':0'

To fix this, add the following lines to your ~/.profile to recreate the symbolic links after every restart. The symbolic links will not survive a restart, that's why i use ~/.profile.

$ cat ~/.profile

if [[ ! -e "${XDG_RUNTIME_DIR}/wayland-0" ]]; then
    ln --symbolic /mnt/wslg/runtime-dir/wayland-0 "${XDG_RUNTIME_DIR}"/wayland-0
    ln --symbolic /mnt/wslg/runtime-dir/wayland-0.lock "${XDG_RUNTIME_DIR}"/wayland-0.lock
fi

Again, if this does not work, give @rahulshamkuwar's solution a try, that fixed some other GUI programs not opening for me.

[jsberg-bnl]

Here's what's going on for at least some of the cases, when you are running systemd:

1. Way early in the process, WSL(g) mounts a copy of /mnt/wslg/.X11-unix at /tmp/.X11-unix
2. systemd mounts a tmpfs at /tmp, thus hiding /tmp/.X11-unix (/usr/lib/systmd/system/tmp.mount).
3. systemd-tmpfiles then proceeds to create a /tmp/.X11-unix directory (/usr/lib/tmpfiles.d/x11.conf)

A simple workaround then is to disable the mount of the tmpfs on /tmp with systemctl mask tmp.mount. systemd-tmpfiles appears to leave WSLg's existing /tmp/.X11-unix alone.

A nicer solution from the WSL end would be when systemd is configured, instead of the early mystery mount at /tmp/.X11-unix, would be to inject a systemd rule for the mount carefully handling the dependencies so that the mount happened after the tmpfs was created on /tmp.

microsoft/WSL#8908 was what guided me to understanding what was going on and is making a similar if not identical suggestion...

[dhtzs]

A nicer solution from the WSL end would be when systemd is configured, instead of the early mystery mount at /tmp/.X11-unix, would be to inject a systemd rule for the mount carefully handling the dependencies so that the mount happened after the tmpfs was created on /tmp.

Totally agree on this one. I really wish the developers could have a closer look at this soon!

[dciarniello]

After almost two years, I've pretty much given up any hope that this issue will be resolved.

[wang1zhen]

yeah, this seems to be the origin of my several recent cases... Since disabling systemd is not favorable for me, the only workaround would be manually creating symlinks for /tmp/.X11-unix.

BTW, Ubuntu wsl seems not to have some issues with this, did they have some special tweaks?

[jeff-kohn]

BTW, Ubuntu wsl seems not to have some issues with this, did they have some special tweaks?

I see this behavior on Ubuntu 24.04, with some gui apps taking 10-20 secs to launch (if ever, sometimes I have to launch a second time).

[zewpo]

@wang1zhen
Did this not work for you?
systemctl mask tmp.mount

[wang1zhen]

@wang1zhen Did this not work for you? systemctl mask tmp.mount

Yes, it worked. Yet I think there is tmp.mount service for some specific reasons right?

[zewpo]

@wang1zhen

Yes, it worked. Yet I think there is tmp.mount service for some specific reasons right?

Normally, yeah, but I think ms wslg image is taking care of it already.

microsoft/WSL#11857

[mati865]

The workaround that allows keeping tmp.mount is described in #1156 (comment)

[Nahor]

A better workaround in this comment (configure the existing tmp.mount service rather than creating a new one)