WSL, WSLg, and systemd hacks

snapd
1

Since I know a lot of folks here use snapd under WSL using either my genie or a different systemd-enabling hack, a word of warning/advice:

  • If you’re using genie, make sure you’ve updated to 1.38 for WSLg compatibility
  • If you aren’t, here’s what breaks and needs fixing:
    • You will need to ensure that the new environment variables are passed through: DISPLAY, WAYLAND_DISPLAY, and PULSE_SERVER .
    • By default, systemd runs systemd-tmpfiles when “booting”, which cleans up various directories and temporary files. This includes /tmp/.X11-unix, which wipes out the link to the socket WSLg’s X server is accessed through, thus ensuring that X applications won’t work either inside or outside the systemd namespace. You need to put this link back after systemd initializes to make X work again; genie does this simply by bind-mounting /mnt/wslg/.X11-unix on top of /tmp/.X11-unix after systemd is up.

Hope this is of use.

3 Likes
2

Or there is my systemd work that handles everything for you, and supports GUI Snaps.

2 Likes
3

Hm. That does look like a better approach to the X11 socket issue. Think I’ll have to steal imitate that for 1.39.

(Did you need to do something special to support GUI snaps? I meant to inquire after seeing your post the other day, because they seem to have been working all along for me once snaps were up and running.)

…actually, while I’m here, have you had any thoughts on how best to coerce GUI apps and snaps launched from the new turn-.desktop-files-into-Start-Menu-shortcuts facilities to launch in the systemd area?

1 Like
4

The enabling of GUI snaps was handled with the following:

  • this file copied to /etc/systemd/system/user-runtime-dir@.service.d/override.conf
  • this file and this file copied to /etc/systemd/system/

The first mounts /mnt/wslg/runtime-dir at /run/user/$UID to ensure that the pulseaudio and wayland sockets are accessible by snaps. The second re-enables the /tmp/.X11-unix socket when systemd mounts /tmp as a new tmpfs mount in the systemd mount namespace.

3 Likes
5

Ah, specifically for WSLg. Gotcha.

Thanks!

1 Like
6

I suspect that systemd-socket-proxyd used like this may cause problems with any extensions that rely on file descriptor passing. DRI3 is the main one here, although I suspect that’s not the only barrier to getting accelerated graphics working. Snaps would also need to have access to the correct driver libraries too.

7

I had that issue with the wayland socket, but the X11 socket seems ok from quick testing… I might have not created the right situation to highlight it tho.

8

As I said, I think DRI3 is the only common user of the feature. And if you don’t have the matching 3D driver available in the sandbox, it may never even attempt to do any fd passing.

1 Like
9

I am using systemd and snap just fine on my WSL on Windows 11. I am on Ubuntu 20.04 and the GUI apps work really well. The only downside is that I can’t seem to make icons work. As far as I know, WSLg only supports desktop files from the global directory right now /usr/share/applications. Snap files are stored in /var/lib/snapd/desktop/applications though so I copy them over which makes them available in my Windows system in the start menu but none of them has their icon.

My gitkraken.desktop file look like this for example:

[Desktop Entry]
X-SnapInstanceName=gitkraken
Version=1.0
Name=GitKraken
Comment=Unleash your repo
GenericName=Git Client
Exec=env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/gitkraken_gitkraken.desktop /snap/bin/gitkraken --no-sandbox %U
Icon=/snap/gitkraken/184/usr/share/gitkraken/gitkraken.png
Type=Application
StartupNotify=true
Terminal=false
Categories=GNOME;GTK;Development;RevisionControl;
MimeType=text/plain;
StartupWMClass=gitkraken

While this works and lets me start GitKraken from my Windows system, it doesn’t have an icon. Is there a known hack for this as well?