X applications are broken after running Genie

[nitanmarcel]

Windows version (build number):

• 22000.556

Linux distribution:
= Bookworm

Genie version:

• genie 2.2

Describe the bug
Again something else's breaking for me after I run the bottle.

X applications don't work anymore (xeyes, xhost). They just show an Error: Can't open display: :0.

Tried some solutions I've found on internet. One of them was using the nameserver from /etc/resolv.conf which it made the error go away but the xeyes process gets stuck. Probably displaying somewhere else?

Confirm that you are running inside the bottle:
Happens after the bottle is ran, even after it's closed (not shutdown).

To Reproduce

1. Install xeyes: apt-get install x11-apps
2. Launch xeyes wait a few good seconds. Make sure the application window has been displayed.
3. Start genie: genie -s

Expected behavior
An window with 2 eyes should show up (see screenshot)

Screenshots

I confirm that I have read the ENTIRE supplied readme file and checked for relevant information on the repository wiki before raising this issue, and that if the solution to this issue is found in either location, it will be closed without further comment:

• Yes.

[cerebrate]

Are you using WSLg or a third-party X server?

[nitanmarcel]

Are you using WSLg or a third-party X server?

Sorry I omitted this part. I forgot about third-parties.

Anyway, I'm using WSLg :)

[cerebrate]

Okay. There's a couple of things to check here. First is the existence of the /tmp/.X11-unix/X0 socket. I expect this will be absent given the errors you're getting, but worth checking anyway. Second is the existence of the /mnt/wslg folder containing all the WSLg stuff, including specifically /mnt/wslg/.X11-unix/X0.

What I'm currently expecting to see is that the former does not exist, but the second does. In which case...

Here's the thing. WSLg works on standard WSL by symlinking the /mnt/wslg/.X11-unix/X0 socket from /tmp/.X11-unix/X0, which latter is where X applications expect to find it. This symlink is deleted when systemd starts up, because just about every distro includes a service designed to clean up and otherwise manage /tmp. To compensate for this, genie installs two systemd units, wslg-xwayland.service and wslg-xwayland.socket, which do the job of creating the X11 socket in the first place and proxying it to the WSLg socket in a systemd-friendly way.

Check that both of these (or just the .socket if no X applications have run yet) are in the active (running) state with systemd status. If they aren't, take a look at the accompanying log and we'll go from there.

(Also, I note that you're getting the error message telling you that your default systemd target isn't multi-user.target . Try fixing this and shutting down/restarting WSL first , before doing any of the above. default.target usually drags in other stuff including distro-native display-type services which could be breaking things, which is why, per error, only multi-user.target is supported.)

[nitanmarcel]

So I followed the steps given by you.

The default target has been set to multi-user.target via:

• systemctl enable multi-user.target
• systemctl set-default multi-user.target

and /tmp/.X11-unix/X0 is missing while /mnt/wslg/.X11-unix/X0 exists. Here's the full content of /mnt/wslg

.   .X11-unix          PulseAudioRDPSource  doc    pulseaudio.log  stderr.log    weston.log
..  PulseAudioRDPSink  PulseServer          dumps  runtime-dir     versions.txt

systemctl status shows no failed units but wslg-xwayland.service and wslg-xwayland.socket are dead.

* wslg-xwayland.service
     Loaded: loaded (/usr/lib/systemd/system/wslg-xwayland.service; static)
     Active: inactive (dead)
TriggeredBy: * wslg-xwayland.socket

* wslg-xwayland.socket
     Loaded: loaded (/usr/lib/systemd/system/wslg-xwayland.socket; disabled; vendor preset: enabled)
     Active: inactive (dead)
   Triggers: * wslg-xwayland.service
  Condition: start condition failed at Mon 2022-03-21 11:00:29 EET; 8min ago
             `- ConditionVirtualization=wsl was not met
     Listen: /tmp/.X11-unix/X0 (Stream)

Mar 21 11:00:29 DESKTOP-0I84KMN-wsl systemd[1]: Condition check resulted in wslg-xwayland.socket being skipped.

Doing journalctl -u wslg-xwayland.service returns no log entries while journalctl -u wslg-xwayland.socket returns systemd[1]: Condition check resulted in wslg-xwayland.socket being skipped.

[nitanmarcel]

Looks to me that it's related to #161

Based on the respective issue I followed the following commands.

The output of the command systemd-detect-virt is microsoft. Also systemd-detect-virt --container returns none and systemd-detect-virt --vm returns microsoft.

Systemd version is:

systemd 247 (247.3-6)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified

[nitanmarcel]

I forgot where I backed up the original wsl2 kernel so I had to compile it once again. After compilation xeyes ran correctly.

Totally related to microsoft/WSL#6911

If there's nothing else you can close this issue and my previous issue related to Atom since it also got fixed after using the default microsoft kernel

[akuropka]

I'm not using wslg together with genie so I did not discover this but I have the same issue with a custom kernel not following the required naming. I am wondering if it would not be more fail-proof if genie checks in the beginning if the link exists and recreates it if so. (I see no downside doing so though the other way is of course more beautiful.) Since wslg is working despite the wsl detection based on the kernel string it's somehow a limitation imposed by genie.

[cerebrate]

I am wondering if it would not be more fail-proof if genie checks in the beginning if the link exists and recreates it if so. (I see no downside doing so though the other way is of course more beautiful.) Since wslg is working despite the wsl detection based on the kernel string it's somehow a limitation imposed by genie.

The problem is ordering.

genie execs unshare systemd at which point it's not running any more. After that, during its startup sequence, systemd may (or may not, depending on configuration) invoke a service (which on Debian is systemd-tmpfiles-setup.service, but not all distros use systemd-tmpfiles) to clean up temporary files/folders, at some point.

Recreating it before this point is useless, obviously. Afterwards, it needs to be done with a systemd service (as the current release does), at which point the link is (probably) already gone, and you need to check that you actually are running inside WSL, hence the ConditionVirtualization. Technically, I suppose, one could just detect that the target of the link exists under /mnt/wslg, but this isn't a surefire way of detecting WSL or that a WSL distro is actually running in WSL, inviting assorted painful bugs.

So I think it is best, at least for now, to stick to the generally accepted method of WSL detection. I will document the constraint on custom kernel naming more visibly.