Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x stops working shortly after restart on WSL2/Win10 #12260

Open
1 of 2 tasks
ajkessel opened this issue Nov 12, 2024 · 6 comments
Open
1 of 2 tasks

x stops working shortly after restart on WSL2/Win10 #12260

ajkessel opened this issue Nov 12, 2024 · 6 comments
Assignees

Comments

@ajkessel
Copy link

Windows Version

10.0.19045.5011

WSL Version

2.3.26.0

Are you using WSL 1 or WSL 2?

  • WSL 2
  • WSL 1

Kernel Version

5.15.167.4-1

Distro Version

Ubuntu 24.10 (Oracular Oriole)

Other Software

No response

Repro Steps

For the past year or two, I've been using X/wslg with no problem. Starting recently, however, I observe different behavior. I'm not sure if this is from a WSL update or perhaps an Ubuntu update--I haven't changed anything else on my system that I'm aware of.

When I launch WSL2, I'm able to open X apps from the command-line without a problem. After a few minutes, though, I get Error: Can't open display: :0. Restarting WSL fixes the issue for a short while and then it reverts again.

Where can I look to narrow down the issue?

Some older postings suggest looking at firewall rules but disabling Windows Defender on the vEthernet NICs does not help, and I don't see any inbound rules for VcXsrv (nor any active VcXsrv pids).

Expected Behavior

X app should open

Actual Behavior

X app does not open

Diagnostic Logs

No response

Copy link

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

@ajkessel
Copy link
Author

Requested logs attached.

WslLogs-2024-11-12_14-34-59.zip

Copy link

Diagnostic information
Detected appx version: 2.3.26.0

@ajkessel
Copy link
Author

I think this may be a variation on #9689 which has been closed. The workaround identified in that issue works for me:

declare -i MyUID=$(id -u)
XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR:-/run/user/$MyUID}
export XDG_RUNTIME_DIR

while findmnt --shadow -n -o SOURCE "$XDG_RUNTIME_DIR" >/dev/null; do
        echo "Unmounting '$XDG_RUNTIME_DIR'" >&2
        sudo umount "$XDG_RUNTIME_DIR"
done

@OneBlue OneBlue self-assigned this Nov 12, 2024
@ajkessel
Copy link
Author

Actually, I misspoke. The fix above was not reliably working and may have just been a coincidence. It turns out the problem is /tmp/.X11-unix is getting overwritten (or mounted) by some process such that it is no longer a symlink to /mnt/wslg/.X11-unix. If I delete /tmp/.X11-unix and relink to the wslg folder, X apps work again. Any ideas how to identify what is causing the overwrite/mount?

@ajkessel
Copy link
Author

I think this is probably wslg issue #1122. I'll leave it open for now for someone with better expertise to confirm if this is a dupe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants