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

Wayland socket is missing when Systemd enabled #357

Open
xuangeyouneihan opened this issue Mar 25, 2024 · 12 comments
Open

Wayland socket is missing when Systemd enabled #357

xuangeyouneihan opened this issue Mar 25, 2024 · 12 comments

Comments

@xuangeyouneihan
Copy link

xuangeyouneihan commented Mar 25, 2024

IMPORTANT
Please read README and Docs before creating the issue.

Please fill out the below information:
Describe the issue
When Systemd on my subsystem started working by accident, I found that all my GUI apps can only be opened via X11. Then I found that there was no wayland-0 in /run/user/1000. I do not know why the socket was gone, but it seems to be related to Systemd. Though I wrote a script as an alternative workaround, the problem has not been really solved. Wayland socket exists in Ubuntu WSL with Systemd running, so it does not seem to be an issue of WSL.

To Reproduce
Just try to make Systemd work

Expected behavior
Wayland socket exists, and GUI apps can use it.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviroment:

  • Windows build number: 10.0.22631.3296
  • Security Software: Windows Defender
  • WSL version 1/2: WSL2
  • ArchWSL version: 24.3.11.0
  • ArchWSL Installer type zip/appx/other clean/update: scoop/zip
  • Launcher version: 23072600

Additional context

  1. To make Systemd work, first I tried to add something to %USERPROFILE%\.wslconfig according to #356 to disable cgroups v1, but it did not work. Then I found another article and modified .wslconfig according to it, and it worked. I renamed .wslconfig to .wslconfig1 without modifying it to enable cgroups v1, and Systemd was also working somehow. But when I tried to rename .wslconfig1 back without modifying it to disable cgroups v1, backup the origional ext4.vhdx, unregister ArchWSL, and then re-install it with a new ext4.vhdx, Systemd did not work. So I actually have no idea about how to make Systemd work.
  2. Eventually, inspired by a post, I wrote a script, which links everything in /mnt/wslg to /run/user/$UID at startup, as an alternative workaround. Copy the content below and paste it to /etc/systemd/system/user-runtime-dir@.service.d/link.conf to "solve" the problem:
    [Service]
    ExecStart = sh -c "ln -fs /mnt/wslg/runtime-dir/* /run/user/"%i
    
@xuangeyouneihan
Copy link
Author

@9numbernine9

Does wayland-0 exist in /run/user/$UID with version 22.10.16.0? I found that wayland-0 is missing in version 24.3.11.0 when Systemd accidentally enabled, see [this issue]

No, it doesn't.

So Wayland does not work, right? If it works, what is $XDG_RUNTIME_DIR?

@viruscamp
Copy link

The root cause is Arch mounts /tmp and /run/user/1000 as tmpfs after startup, make the existing /tmp/.X11-unit/X0 and /run/user/1000/wayland-0 unavailable.

Disable tmp.mount is one useful solution, but I recommend:

$ cat /etc/tmpfiles.d/wslg.conf
# See tmpfiles.d(5) for details
# link WSLg display files after system started

# Type Path              Mode UID  GID  Age Argument
L+     /tmp/.X11-unix/X0 -    -    -    -   /mnt/wslg/.X11-unix/X0

I have no idea how to disable mounting /run/user/1000 as tmpfs, so I recommend:

$ cat ~/.config/user-tmpfiles.d/wslg.conf
# Type Path              Mode UID  GID  Age Argument
L+     %t/wayland-0      -    -    -    -   /mnt/wslg/runtime-dir/wayland-0
L+     %t/wayland-0.lock -    -    -    -   /mnt/wslg/runtime-dir/wayland-0.lock
L+     %t/pulse/native   -    -    -    -   /mnt/wslg/runtime-dir/pulse/native
L+     %t/pulse/pid      -    -    -    -   /mnt/wslg/runtime-dir/pulse/pid
L+     %t/dbus-1         -    -    -    -   /mnt/wslg/runtime-dir/dbus-1

$ systemctl --user enable systemd-tmpfiles-setup.service systemd-tmpfiles-clean.timer

@xuangeyouneihan
Copy link
Author

xuangeyouneihan commented Apr 17, 2024

The root cause is Arch mounts /tmp and /run/user/1000 as tmpfs after startup, make the existing /tmp/.X11-unit/X0 and /run/user/1000/wayland-0 unavailable.

Disable tmp.mount is one useful solution, but I recommend:

$ cat /etc/tmpfiles.d/wslg.conf
# See tmpfiles.d(5) for details
# link WSLg display files after system started

# Type Path              Mode UID  GID  Age Argument
L+     /tmp/.X11-unix/X0 -    -    -    -   /mnt/wslg/.X11-unix/X0

I have no idea how to disable mounting /run/user/1000 as tmpfs, so I recommend:

$ cat ~/.config/user-tmpfiles.d/wslg.conf
# Type Path              Mode UID  GID  Age Argument
L+     %t/wayland-0      -    -    -    -   /mnt/wslg/runtime-dir/wayland-0
L+     %t/wayland-0.lock -    -    -    -   /mnt/wslg/runtime-dir/wayland-0.lock
L+     %t/pulse/native   -    -    -    -   /mnt/wslg/runtime-dir/pulse/native
L+     %t/pulse/pid      -    -    -    -   /mnt/wslg/runtime-dir/pulse/pid
L+     %t/dbus-1         -    -    -    -   /mnt/wslg/runtime-dir/dbus-1

$ systemctl --user enable systemd-tmpfiles-setup.service systemd-tmpfiles-clean.timer

Does %t refer to $XDG_RUNTIME_DIR? Also, I tried to add L+ /run/user/1000/wayland-0 - - - - /mnt/wslg/runtime-dir/wayland-0 to /etc/tmpfiles.d/wslg.conf, but it did not work, why?

Add: I added the content that links files in /mnt/wslg/runtime-dir to /etc/tmpfile.d/wslg.conf, but it did not work. Must I add the content to ~/.config/user-tmpfile.d/wslg.conf? If so, I think my workaround might be better, since it works globally, not just for one user.

@viruscamp
Copy link

viruscamp commented Apr 18, 2024

  1. system-tmpfiles.d and user-tmpfiles.d are different services, you cannot write conf in one file
  • /usr/lib/systemd/system/systemd-tmpfiles-setup.service
  • /usr/lib/systemd/user/systemd-tmpfiles-setup.service
  1. Writing /run/user/1000/wayland-0 to /etc/tmpfiles.d/ is useless
  • file owner and group are wrong
  • /run/user/1000/ will be remounted as tmpfs later, clear the file
  1. The only global conf location for user-tmpfiles.d is /usr/share/user-tmpfiles.d/*.conf
    but user systemd-tmpfiles-setup is not enabled by default in arch, you have to enable it for each user.

  2. this user service may work globally for each user(incomplete and untested):

$ cat /etc/systemd/user/wslg-user-runtime-dir.service
[Service]
ExecStart = sh -c "ln -fs /mnt/wslg/runtime-dir/* "%t

@xuangeyouneihan
Copy link
Author

xuangeyouneihan commented Apr 18, 2024

  1. system-tmpfiles.d and user-tmpfiles.d are different services, you cannot write conf in one file

    • /usr/lib/systemd/system/systemd-tmpfiles-setup.service

    • /usr/lib/systemd/user/systemd-tmpfiles-setup.service

    1. Writing /run/user/1000/wayland-0 to /etc/tmpfiles.d/ is useless
    • file owner and group are wrong

    • /run/user/1000/ will be remounted as tmpfs later, clear the file

    1. The only global conf location for user-tmpfiles.d is /usr/share/user-tmpfiles.d/*.conf
      but user systemd-tmpfiles-setup is not enabled by default in arch, you have to enable it for each user.

    2. this user service may work globally for each user(incomplete and untested):

$ cat /etc/systemd/user/wslg-user-runtime-dir.service
[Service]
ExecStart = sh -c "ln -fs /mnt/wslg/runtime-dir/* /run/user/"%i

Well, I think 4 should work, because my link.conf is completely same with your wslg-user-runtime-dir.service, and I'm using it.

@viruscamp
Copy link

We'd better use %t as XDG_RUNTIME_DIR

$ cat /etc/systemd/user/wslg-user-runtime-dir.service
[Service]
ExecStart = sh -c "ln -fs /mnt/wslg/runtime-dir/* "%t

@xuangeyouneihan
Copy link
Author

xuangeyouneihan commented Apr 18, 2024

We'd better use %t as XDG_RUNTIME_DIR

$ cat /etc/systemd/user/wslg-user-runtime-dir.service
[Service]
ExecStart = sh -c "ln -fs /mnt/wslg/runtime-dir/* "%t

I've tried this, but it did not work in my link.conf. Maybe I need to export "ln -fs /mnt/wslg/runtime-dir/* "%t to a file to find out why it didn't work

@xuangeyouneihan
Copy link
Author

We'd better use %t as XDG_RUNTIME_DIR

$ cat /etc/systemd/user/wslg-user-runtime-dir.service
[Service]
ExecStart = sh -c "ln -fs /mnt/wslg/runtime-dir/* "%t

I've tried this, but it did not work in my link.conf. Maybe I need to export "ln -fs /mnt/wslg/runtime-dir/* "%t to a file to find out why it didn't work

Well, I added sh -c "echo "%t" > /home/[username]/aaa.txt" in my link.conf, and found that %t is /run.

As for your systemd-tmpfiles-setup.service, I could not even start it. When I inputed sudo systemctl start /etc/systemd/user/wslg-user-runtime-dir.service in my terminal, it told me "Failed to start etc-systemd-user-wslg\x2duser\x2druntime\x2ddir.service.mount: Unit etc-systemd-user-wslg\x2duser\x2druntime\x2ddir.service.mount not found."; when I typed sudo systemctl start wslg-user-runtime-dir.service, it said "Failed to start wslg-user-runtime-dir.service: Unit wslg-user-runtime-dir.service not found." Please tell me how to start it. Thanks 😂

@viruscamp
Copy link

I guess that your /etc/systemd/system/user-runtime-dir@.service.d/link.conf is part of user init process, not a standalone user service.

User's XDG_RUNTIME_DIR is not done , when sh -c "ln -fs /mnt/wslg/runtime-dir/* "%t executed.

@xuangeyouneihan
Copy link
Author

Maybe. BTW, do you know how to start your wslg-user-runtime-dir.service?

@viruscamp
Copy link

$ cat /etc/systemd/user/wslg-runtime-dir.service
[Service]
Type=oneshot
ExecStart=sh -c "ln -fs /mnt/wslg/runtime-dir/* "%t

[Install]
WantedBy=default.target

$ sudo systemctl --global enable wslg-runtime-dir
Created symlink /etc/systemd/user/default.target.wants/wslg-runtime-dir.service → /etc/systemd/user/wslg-runtime-dir.service.

@xuangeyouneihan
Copy link
Author

It works! Thank you so much!

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