Attempting to run GUI apps returns an error #19

zacharee · 2021-04-21T20:29:48Z

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

Update to Windows build 21364.
Install special NVIDIA 470.14 driver.
Run wsl --update.
Reboot.
Create new Ubuntu 20.04 WSL2 instance.
Install GUI applications (x11-apps, Chrome, etc.).
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.

The text was updated successfully, but these errors were encountered:

rpw138 · 2021-04-21T20:47:46Z

I'm having the same issue.

spronovo · 2021-04-21T22:07:15Z

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 · 2021-04-21T22:17:34Z

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 · 2021-04-21T22:25:10Z

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 · 2021-04-21T22:30:12Z

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 · 2021-04-21T22:51:09Z

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 · 2021-04-21T22:58:41Z

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 · 2021-04-21T23:15:06Z

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 · 2021-04-21T23:19:41Z

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 · 2021-04-21T23:20:54Z

@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 · 2021-04-21T23:22:42Z

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 · 2021-04-21T23:44:39Z

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 · 2021-04-21T23:52:44Z

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 · 2021-04-22T00:07:45Z

@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 · 2021-04-22T00:08:33Z

This is my configuration.

spronovo · 2021-04-22T00:12:24Z

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 · 2021-04-22T00:26:31Z

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

zacharee · 2021-04-22T01:58:16Z

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

spronovo · 2021-04-22T02:05:35Z

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

spronovo · 2021-04-22T04:36:37Z

@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 · 2021-04-22T08:50:48Z

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 · 2021-04-22T09:44:25Z

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 · 2021-04-22T12:49:44Z

@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 · 2021-04-22T13:27:41Z

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

spronovo · 2021-04-22T15:24:41Z

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 · 2021-04-22T15:30:40Z

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 · 2021-04-22T15:39:26Z

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

noce2 · 2021-04-24T19:21:50Z

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 · 2021-04-26T00:42:59Z

@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 · 2021-04-27T02:26:55Z

@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 · 2021-04-27T02:32:44Z

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 · 2021-04-27T02:35:12Z

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 · 2021-04-27T02:38:56Z

Cool, which game?

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

framerate · 2021-04-27T02:41:47Z

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 · 2021-04-27T11:43:18Z

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 · 2021-04-27T15:29:53Z

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 · 2021-04-27T15:51:26Z

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

noce2 · 2021-04-27T20:36:29Z

@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 · 2021-04-30T20:52:32Z

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 · 2021-04-30T21:08:21Z

@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 · 2021-04-30T23:54:23Z

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

framerate · 2021-05-01T00:21:55Z

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

edmondium · 2024-02-22T15:05:34Z

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

Update to Windows build 21364.

Install special NVIDIA 470.14 driver.

Run wsl --update.

Reboot.

Create new Ubuntu 20.04 WSL2 instance.

Install GUI applications (x11-apps, Chrome, etc.).

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.

zacharee added the bug Something isn't working label Apr 21, 2021

benhillis self-assigned this Apr 22, 2021

spronovo closed this as completed Apr 22, 2021

spronovo reopened this Apr 22, 2021

pecigonzalo mentioned this issue Apr 22, 2021

Init /tmp/.X11-unix is overwritten by mounts #43

Open

noomz mentioned this issue Apr 23, 2021

cannot open display: :0 #62

Closed

spronovo assigned spronovo and unassigned benhillis Apr 26, 2021

spronovo added the fixinbound label Apr 26, 2021

spronovo assigned hideyukn88 Apr 26, 2021

This was referenced Apr 29, 2021

WSLg RDP connection crashes with specific display setups #124

Closed

WSLg won't work on 4 monitor system #122

Closed

Can't open display error when trying to launch apps #134

Closed

spronovo closed this as completed Apr 30, 2021

badjames mentioned this issue Jun 17, 2021

5 second delay when opening Xt dialogs #307

Closed

Attempting to run GUI apps returns an error #19

Attempting to run GUI apps returns an error #19

Comments

zacharee commented Apr 21, 2021 • edited Loading

Environment

Steps to reproduce

Expected behavior

Actual behavior

rpw138 commented Apr 21, 2021

spronovo commented Apr 21, 2021

pecigonzalo commented Apr 21, 2021

spronovo commented Apr 21, 2021

spronovo commented Apr 21, 2021

pecigonzalo commented Apr 21, 2021 via email

pecigonzalo commented Apr 21, 2021 • edited Loading

rpw138 commented Apr 21, 2021 • edited Loading

spronovo commented Apr 21, 2021

spronovo commented Apr 21, 2021

zacharee commented Apr 21, 2021

rpw138 commented Apr 21, 2021 • edited Loading

zacharee commented Apr 21, 2021

spronovo commented Apr 22, 2021

zacharee commented Apr 22, 2021

spronovo commented Apr 22, 2021

hideyukn88 commented Apr 22, 2021

zacharee commented Apr 22, 2021 • edited Loading

spronovo commented Apr 22, 2021

spronovo commented Apr 22, 2021

naphta commented Apr 22, 2021

pecigonzalo commented Apr 22, 2021

rpw138 commented Apr 22, 2021

rpw138 commented Apr 22, 2021

spronovo commented Apr 22, 2021

spronovo commented Apr 22, 2021

rpw138 commented Apr 22, 2021

noce2 commented Apr 24, 2021

spronovo commented Apr 26, 2021

framerate commented Apr 27, 2021

spronovo commented Apr 27, 2021

framerate commented Apr 27, 2021 • edited Loading

spronovo commented Apr 27, 2021

framerate commented Apr 27, 2021 • edited Loading

pahosler commented Apr 27, 2021

Ghiora commented Apr 27, 2021

spronovo commented Apr 27, 2021

noce2 commented Apr 27, 2021

spronovo commented Apr 30, 2021

framerate commented Apr 30, 2021

spronovo commented Apr 30, 2021

framerate commented May 1, 2021

edmondium commented Feb 22, 2024

Environment

Steps to reproduce

Expected behavior

Actual behavior

zacharee commented Apr 21, 2021 •

edited

Loading

pecigonzalo commented Apr 21, 2021 •

edited

Loading

rpw138 commented Apr 21, 2021 •

edited

Loading

rpw138 commented Apr 21, 2021 •

edited

Loading

zacharee commented Apr 22, 2021 •

edited

Loading

framerate commented Apr 27, 2021 •

edited

Loading

framerate commented Apr 27, 2021 •

edited

Loading