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