Attempting to run GUI apps returns an error

[zacharee]

Environment

Windows build number: Microsoft Windows [Version 10.0.21364.1]
Your Distribution version: Ubuntu 20.04
Your WSLg version: 1.0.17.1

Steps to reproduce

1. Update to Windows build 21364.
2. Install special NVIDIA 470.14 driver.
3. Run wsl --update.
4. Reboot.
5. Create new Ubuntu 20.04 WSL2 instance.
6. Install GUI applications (x11-apps, Chrome, etc.).
7. Attempt to run the applications.

WSL logs:

pulseaudio.log
weston.log
versions.txt

Expected behavior

GUI applications should open when run.

Actual behavior

Attempting to launch from the CLI returns the error: Error: Can't open display: :0.

[rpw138]

I'm having the same issue.

[spronovo]

From the log it looks like Weston is running and Xwayland is properly listening on display :0, maybe there is something wrong with the socket projection. Can you try this:

spronovo@OFFICE:~$ ls -la /tmp/.X11-unix
lrwxrwxrwx 1 root root 19 Apr 21 12:12 /tmp/.X11-unix -> /mnt/wslg/.X11-unix

spronovo@OFFICE:~$ ls -la /tmp/.X11-unix/
total 0
drwxrwxrwx 2 root     root   60 Apr 21 12:22 .
drwxrwxrwt 5 root     root  220 Apr 21 12:22 ..
srwxrwxrwx 1 spronovo users   0 Apr 21 12:22 X0

Do you see the socket X0 projected from /mnt/wslg/.X11-unix/X0?

[pecigonzalo]

I found the same problem in my Ubuntu installation. On a vanilla Debian the /tmp/.X11-unix is there but in my Ubuntu it is not. What process is setting that up? Maybe I can review what could be interrupting it.

[spronovo]

We setup the link from /tmp/.X11-unix to /mnt/wslg/.X11-unix during our custom INIT before Ubuntu is launched... Then Weston running in the system distro create it's socket in /mnt/wslg/.X11-unix... and they end up appearing in your user distro as well.

Which version of Ubuntu are you using? Do you have something in your init script that would maybe wipe the content of /tmp?

[spronovo]

Also if you could try recreating the link to see if that's the only problem.

ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

Do X11 app start after that? If you can help us understand how the link get wiped on your system that would be much appreciated as we don't see this on our end :-).

[pecigonzalo]

Yeah, I'm trying to find the same as well. Either something wiping it or preventing it from being created. I'm away from terminal for some hours but I did confirm that manually creating the file did make firefox and a bunch of other apps work that were failing before. I'd there a list of files or envs that get injected (happy to read through some sourcecode)? So I can verify all of them.

…

On Thu, Apr 22, 2021, 12:30 AM Steve Pronovost ***@***.***> wrote: Also if you could try recreating the link to see if that's the only problem. ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix Do X11 app start after that? If you can help us understand how the link get wiped on your system that would be much appreciated as we don't see this on our end :-). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACLS7CMZYUCQHLWD6ENU3WTTJ5GYLANCNFSM43LCU4YQ> .

[pecigonzalo]

I believe it might be the fact that I have tmpfs /tmp tmpfs rw,nodev,nosuid,size=2G 0 0 in /etc/fstab and likely being created after init.

EDIT:

Yes, removing that made it work again, but I like keeping /tmp as tmpfs as otherwise it gets constantly filled with, well... temp stuff. Is there a way to change the other of when its created?

[rpw138]

Also if you could try recreating the link to see if that's the only problem.

ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

Do X11 app start after that? If you can help us understand how the link get wiped on your system that would be much appreciated as we don't see this on our end :-).

This did not resolve my issue.

ls -la /tmp/.X11-unix/ was empty

[spronovo]

ah, that makes sense, thanks for tracking that down.

Unfortunately for X11 we don't have a choice on the location of the socket... it has to be at /tmp/.X11-Unix as this is where X11 client are hardcoded to look at. In Wayland the location of the socket is specified in an environment variable so we're not dependent on mapping from /tmp for Wayland native app. This link is being setup as part of the WSL private INIT before the user distro take over. Once the user distro takes over, we don't have any hook back to do further configurations... so we setup everything up front. But if you overwrite /tmp later on, that undo the setup we did.

We'll need to think about this some more and loop-in @benhillis.

For the time being, folks that want to override their /tmp will need to manually recreate the link to get GUI application to work properly.

[spronovo]

@zacharee, @rpw138, could you verify if you are also overriding your /tmp? And if so try recreating the link

ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

[zacharee]

I'm not intentionally doing anything with /tmp. I even created a fresh Ubuntu 20.04 instance to make sure something in my current config wasn't interfering.

I'm away from my computer right now, so I can't try the command yet.

[rpw138]

ls -la /tmp/.X11-unix/

Duplicate of # #

@zacharee, @rpw138, could you verify if you are also overriding your /tmp? And if so try recreating the link

ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

I received the following: ln: failed to create symbolic link /tmp/.X11-unix': File exists

[zacharee]

My system also has both /tmp/.X11-unix and /mnt/wslg/.X11-unix. I think @pecigonzalo's issue might be unrelated.

Here's the command output:

root@ZORIGIN:/mnt/c/Users/Zacha# ls -la /tmp/.X11-unix
lrwxrwxrwx 1 root root 19 Apr 21 19:49 /tmp/.X11-unix -> /mnt/wslg/.X11-unix
root@ZORIGIN:/mnt/c/Users/Zacha# ls -la /mnt/wslg/.X11-unix/
total 0
drwxrwxrwx 2 root    root   60 Apr 21 19:51 .
drwxrwxrwt 5 root    root  180 Apr 21 19:49 ..
srwxrwxrwx 1 zachary users   0 Apr 21 19:51 X0
root@ZORIGIN:/mnt/c/Users/Zacha#

[spronovo]

@zacharee your issue is indeed different, it looks like your monitor configuration throw us off and cause a failure when initializing our rdp-backend. Could you quickly share what things look like from the Windows Display setting page

[zacharee]

This is my configuration.

[spronovo]

We'll repro this locally and fix this... can you try moving monitor 1 to be on the right of 2... i suspect it will fix your issue

[hideyukn88]

@spronovo @zacharee , I understood the problem in monitor placement. I will have a fix shortly.

[zacharee]

Just to confirm it, moving monitor 1 to be inline with the rest made it work.

[spronovo]

Thanks @zacharee, we understand the problem and will have the fix in the next version of WSLg.

[spronovo]

@rpw138 could you verify if you are hitting the same issue as zacharee. Do you happen to run multi-monitor in a configuration where the monitor are not all either vertical stacked or horizontally stack but a mix of both? If not, could you reply and attach your /mnt/wslg/weston.log to this thread.

[naphta]

Thanks @zacharee, we understand the problem and will have the fix in the next version of WSLg.

Just to be selfishly curious what sort of ETA are we looking at for that? Exactly the same issue here, rearrange display and it sparks to life.

[pecigonzalo]

ah, that makes sense, thanks for tracking that down.

Unfortunately for X11 we don't have a choice on the location of the socket... it has to be at /tmp/.X11-Unix as this is where X11 client are hardcoded to look at. In Wayland the location of the socket is specified in an environment variable so we're not dependent on mapping from /tmp for Wayland native app. This link is being setup as part of the WSL private INIT before the user distro take over. Once the user distro takes over, we don't have any hook back to do further configurations... so we setup everything up front. But if you overwrite /tmp later on, that undo the setup we did.

We'll need to think about this some more and loop-in @benhillis.

For the time being, folks that want to override their /tmp will need to manually recreate the link to get GUI application to work properly.

@spronovo Yes, I know that has to be the location, but I was wondering if we could change the process to inject those after fstabs are mounted. That way we can maintain the normal Linux workflow.

It seems like that is a separate issue than the one OP is having. Should I split this up to another issue or a conversation? Or would you like to do so?

[rpw138]

@rpw138 could you verify if you are hitting the same issue as zacharee. Do you happen to run multi-monitor in a configuration where the monitor are not all either vertical stacked or horizontally stack but a mix of both? If not, could you reply and attach your /mnt/wslg/weston.log to this thread.

@spronovo Coincidentally, I was trying this on my laptop without a dock - so its a single screen laptop. The directory you mentioned is not present.

[rpw138]

@spronovo - Apologies - it looks like my Windows Insider build was old - I will update and report back

[spronovo]

Thanks @zacharee, we understand the problem and will have the fix in the next version of WSLg.

Just to be selfishly curious what sort of ETA are we looking at for that? Exactly the same issue here, rearrange display and it sparks to life.

We'll have an update out by early next week.

[spronovo]

ah, that makes sense, thanks for tracking that down.
Unfortunately for X11 we don't have a choice on the location of the socket... it has to be at /tmp/.X11-Unix as this is where X11 client are hardcoded to look at. In Wayland the location of the socket is specified in an environment variable so we're not dependent on mapping from /tmp for Wayland native app. This link is being setup as part of the WSL private INIT before the user distro take over. Once the user distro takes over, we don't have any hook back to do further configurations... so we setup everything up front. But if you overwrite /tmp later on, that undo the setup we did.
We'll need to think about this some more and loop-in @benhillis.
For the time being, folks that want to override their /tmp will need to manually recreate the link to get GUI application to work properly.

@spronovo Yes, I know that has to be the location, but I was wondering if we could change the process to inject those after fstabs are mounted. That way we can maintain the normal Linux workflow.

It seems like that is a separate issue than the one OP is having. Should I split this up to another issue or a conversation? Or would you like to do so?

Agreed, after a bit more research it looks like it's actually our init that is processing these... so we should be able to swap the order to address this i think. Will chat about this with @benhillis next week. Please go ahead and split this into a separate issue.

[rpw138]

@spronovo It work well after the upgrade. Thanks - what a great feature!

[noce2]

From the log it looks like Weston is running and Xwayland is properly listening on display :0, maybe there is something wrong with the socket projection. Can you try this:

spronovo@OFFICE:~$ ls -la /tmp/.X11-unix
lrwxrwxrwx 1 root root 19 Apr 21 12:12 /tmp/.X11-unix -> /mnt/wslg/.X11-unix

spronovo@OFFICE:~$ ls -la /tmp/.X11-unix/
total 0
drwxrwxrwx 2 root     root   60 Apr 21 12:22 .
drwxrwxrwt 5 root     root  220 Apr 21 12:22 ..
srwxrwxrwx 1 spronovo users   0 Apr 21 12:22 X0

Do you see the socket X0 projected from /mnt/wslg/.X11-unix/X0?

Hi @spronovo , I also get the display error but when I run the ls command, I have an X1 socket instead of an X0 socket. Could that be part of the issues?

[spronovo]

@noce2 would you mind creating a new issue for yours, it looks like you are hitting different issue than the monitor configuration and fstab issue discuss in this thread. We have fixes on their way for both of those issues.

While filling the new issue, could you dump the content of the DISPLAY environment variable, run both ls -la /tmp/.X11-unix and ls -la /tmp/.X11-unix/ and attach your /mnt/wslg/weston.log to the bug... if you are only seeing a socket on X1 something strange happened :-).

[framerate]

@spronovo sorry for the out of place comment, but i'm trying to see which issue to follow for the vertical monitor configuration bug?

Obviously tons of programmers are going to use WSLg and we often have a mix of vertical (for code and reddit) and horizontal (for everything else :P) monitors.

I just want to follow so I know when I can try again! Point me in the right direction (or instruct me to make a new issue)

[spronovo]

This is the issue tracking the monitor configuration problem. We have a fix in house which we hope to release out later this week barring no unforeseen delays. Note that it's ok to have landscape and portrait monitor... the problem is if you connect some monitor horizontally while connecting other vertically (like the configuration earlier in the thread with 3 monitor connected vertically, and an additional monitor below it).

[framerate]

hmmm ok great.

FYI my monitors are:
15" horizontal above ------> [ ]
ultra wide 34" horiz---> [ ] [ ] <------ 24" vertical next to the ultrawide

I use WSL2 for game development and am super excited for this since I don't have to use third party X11 server any more (and maybe you guys got audio working? O.o)

[spronovo]

Cool, which game?

That configuration will indeed fail at the moment, but will work correctly with the upcoming update.

[framerate]

Cool, which game?

I made a javascript-based (electron) game engine for 2d games, mainly for my Collectible card game (https://store.steampowered.com/app/723410/Doomtrooper_CCG/) but I've been making a few short horror titles too.

That configuration will indeed fail at the moment, but will work correctly with the upcoming update.

Great! I can't wait. I have it all setup so I'll watch this thread for news.

Appreciate you guys' hard work on this. WSL2 (and now WSLg) has done the impossible... brought me back from my Linux box to Windows 10 gasp

"College me" would be pissed, for sure!

[pahosler]

Was having a similar issue display not found. Still do with some apps on vanilla Ubuntu, and apps show errors or warnings in the cli. Ubuntu-20.04 doesn't seem to suffer from the same issues. I did, however, have to reorder my displays in settings to get anything to work at all. This isn't a deal breaker, but it is annoying.

I've been using Linux as my daily driver since 1999, Windows 10 is slowly but surely winning me over. I'm not sure if this makes me h8 MS more or less yet🤔
please don't eff it up 😋
Also, can someone get us an i3 window manager as an option... please

[Ghiora]

In my case I had left over .X11 files and X12, X13 directories in /tmp/ from some X11 Windows server I had running in August 2020.
Those where owned by root. Deleting them solved the issue.. Obviously not the generic problem.

[spronovo]

@pahosler could you take a peek at: https://github.com/microsoft/wslg/wiki/Diagnosing-%22cannot-open-display%22-type-issues

[noce2]

@noce2 would you mind creating a new issue for yours, it looks like you are hitting different issue than the monitor configuration and fstab issue discuss in this thread. We have fixes on their way for both of those issues.

While filling the new issue, could you dump the content of the DISPLAY environment variable, run both ls -la /tmp/.X11-unix and ls -la /tmp/.X11-unix/ and attach your /mnt/wslg/weston.log to the bug... if you are only seeing a socket on X1 something strange happened :-).

@spronovo As a last resort, I rm -rfed the socket and the symlink, and now I get the expected contents for the folder (and I no longer get the display not found error). I'm not sure what the cause of this was but I can say I had previously installed kali-linux and X410 as means of getting the experience that wslg now provides.

[spronovo]

This should be fixed with v1.0.19 that we just released moments ago. To update your WSL install, make sure to save your work than type the following from an elevated command prompt in Windows:

wsl --shutdown
wsl --update

[framerate]

@spronovo just wanted to drop in and high five you. My dev machine just leveled up majorly, being able to do GUI apps without any hacks and SOUND IS BACK.

Thanks for all your hard work, and the implementation is so nice for a first release!)

Thanks for fixing the monitor configuration issues!

[spronovo]

We appreciate the kind words :-), glad this is working out for you. The thanks for the multi-mon fix goes to @hideyukn88.

[framerate]

Well, props to @hideyukn88 too then! Made my weekend. ♥️

[edmondium]

Environment

Windows build number: Microsoft Windows [Version 10.0.21364.1]
Your Distribution version: Ubuntu 20.04
Your WSLg version: 1.0.17.1

Steps to reproduce

1. Update to Windows build 21364.
2. Install special NVIDIA 470.14 driver.
3. Run wsl --update.
4. Reboot.
5. Create new Ubuntu 20.04 WSL2 instance.
6. Install GUI applications (x11-apps, Chrome, etc.).
7. Attempt to run the applications.

WSL logs:

pulseaudio.log weston.log versions.txt

Expected behavior

GUI applications should open when run.

Actual behavior

Attempting to launch from the CLI returns the error: Error: Can't open display: :0.

To make it work, create /etc/tmpfiles.d/wslg.conf file with the following content:

#  This file is part of the debianisation of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

# See tmpfiles.d(5) for details

# Type Path           Mode UID  GID  Age Argument
L+     /tmp/.X11-unix -    -    -    -   /mnt/wslg/.X11-unix

then restart WSL.