2

I am trying to run a program with a GUI on Arch, but it complains that it cannot initialize GTK. The same program works perfectly fine on Ubuntu. Both distributions have DISPLAY set to :0.

Graphical programs were working as expected a few days ago, and I do not remember changing anything which could be relevant.

I have tried launching an X server using XLaunch, which did not appear to have any effect.
Restarting WSL and my computer did not fix the issue, and neither did updating Arch or WSL.
Launching different graphical programs, such as gtkwave or xterm, had the same result. (xterm says Can't open display :0)
Going back in time did not work, as I do not have access to a time machine.
The programs do run as expected in Ubuntu, however I would prefer to use Arch when possible.

PerkyElixir22
  • 23
  • Glad you reposted this over here. Repeating and expanding on my question/comment on SO - (1) Any Systemd in play in either of the WSL instances? (2) Is it just GTK apps? Does a non-GTK graphical app (e.g. xterm) launch in Arch? – NotTheDr01ds Mar 08 '24 at 18:42
  • @NotTheDr01ds Both have systemd=true in /etc/wsl.conf, however I do not know if that is what I am looking for. xterm does not work (see above) – PerkyElixir22 Mar 08 '24 at 18:46
  • Ah, oops - Failed to read the part about xterm that is so clearly there - Apologies and thanks. Let me do some testing - It's been a while since I looked at this, but I seem to recall that if two distros are running Systemd in WSL, there are issues with the display. – NotTheDr01ds Mar 08 '24 at 19:00
  • What's your wsl --version? Just thinking through the fact that it was "working as expected a few days ago". There was a new WSL release last week, but there really isn't much in the way of release notes, other than "minor" that might indicate a change that could break this. – NotTheDr01ds Mar 08 '24 at 19:07
  • WSL version is 2.1.4.0, kernel is 5.15.146.1-2, wslg is 1.0.60 – PerkyElixir22 Mar 08 '24 at 19:08
  • If you don't need Systemd, it's probably worth setting both to syste,d=false (or just commenting out) in the /etc/wsl.conf to see if it makes a difference. – NotTheDr01ds Mar 08 '24 at 19:08
  • Okay, 2.1.4.0 is the latest, so the fact that it updated could be the thing that changed. – NotTheDr01ds Mar 08 '24 at 19:08
  • 1
    seems disabling systemd worked – PerkyElixir22 Mar 08 '24 at 19:12
  • Good to hear, I guess. Most likely something in the way /mnt/wslg is being mounted (or not) when Systemd is running in both distros. Like I said, it's been a while since I looked at that particular combination - I tend to avoid Systemd in WSL unless I need it for testing something in particular. – NotTheDr01ds Mar 08 '24 at 19:18

1 Answers1

2

Resolved (at least with a workaround) in the comments. And I've now seen what seem to be 3 related questions in the last week about this, so there may be significant issue.

I believe there's a common theme of:

  1. Recent update of WSL2 to 2.1.5 (or 1 previous beta)
  2. Systemd being enabled
  3. Non-Ubuntu (perhaps non-Debian) distribution

If you don't have at least the first two of these, then you are probably looking at a different issue. I'm guessing it's possible for the problem to occur on Ubuntu, but something about the current Systemd loading order on that distro appears to be working to avoid the issue for the most part.

For this particular quetion, the issue was caused when running Systemd inside Arch on WSL2 release 2.1.4, and the issue resolved when disabling Systemd.

That leads up to ...

Option 1: Disable Systemd

If you do not need Systemd in WSL. Run:

sudo -e /etc/wsl.conf

If you have:

[boot]
systemd=true

Then either comment out the system line or set it to false.

Shutdown WSL (or terminate the instance) and restart. This can be done via PowerShell with:

wsl --shutdown

Option 2: Create a link for the X11 socket

If you still need or want to run Systemd, there's another answer here on Super User with a solution that I believe is likely to resolve the issue. The solution from that answer is to:

rmdir /tmp/.X11-unix && ln -s /mmnt/wslg/.X11-unix /tmp/.X11-unix

That answer also includes a Systemd unit to automatically handle this on every boot. However, I do recommend occasionally checking to see if there are reports of the issue being fixed, so that you can stop this manually linking in the future. It's possible (but not expected) for this to interfere with other behavior.

For reference, this answer (currently closed, but will probably be Roomba'd at some point) is another case, with a WSL update, OpenSUSE Tumbleweed, and Systemd enabled. Disabling Systemd also resolved that case.

NotTheDr01ds
  • 21,923
  • I shouldn't have to say this (and I can't in the answer itself, but can as a comment), but if you find the information in the other answer that I linked here helpful, I'd much rather you upvote that user's answer than mine, as it is the original source. – NotTheDr01ds Mar 16 '24 at 01:57