systemd doesn't create user (d)bus
#8842
Comments
mangkoran
changed the title
systemd doesn't create user bussystemd doesn't create user (d)bus
|
This is an artifact of how WSL creates shells/commands when you run them; i.e., just spawning them directly. It doesn't go through the normal Linux login process (or variants of same) and thus doesn't invoke PAM, and it's the systemd PAM module that creates a login session and spawns a user systemd (and thus session dbus) for it. (You can see this if you run loginctl, which will tell you there are no established login sessions.) I got around this in genie by installing systemd-machined, which then let me use wsl sudo machinectl shell [email protected] to create a proper login session. This same workaround does the same under the Microsoft systemd implementation, and produces the expected user systemd and session dbus. Hopefully in the future the WSL team can incorporate the needed PAM-triggering functionality directly into wsl.exe. |
|
Thank you for your insight. Now that we know what are the missing "step" from WSL invocation. I do however see my user from Is it because I run |
|
Yes, turning on linger will create the user session/user systemd instance/session bus as part of the systemd start process. I believe you'll still need to use the/a workaround to get inside the user session before you can make (reliable) use of them, though. |
|
the variables $XDG_RUNTIME_DIR and $DBUS_SESSION_BUS_ADDRESS are not created by systemd, the evidence is that the value of $XDG_RUNTIME_DIR is with a trailing character '/', which is not the behavior of systemd. |
I think a better way is to give up /init and let systemd take over everything in the VM. Because by using systemd, most of /init's functionality is redundant. MS engineers just need to implement a few systemd services to be responsible for host interaction things such as sync and interop. |
Actually, they are. For the latter, see /usr/lib/systemd/user/dbus.socket, where the DBUS_SESSION_BUS_ADDRESS variable is set in the session base environment; the former is set by pam_systemd during login (see here: https://www.freedesktop.org/software/systemd/man/pam_systemd.html). It's not a problem with the Microsoft /init per se. It's the general problem that creating a process as a user does not necessarily create a user session for that user; you have to go through one of the routes that call upon PAM for that. |
|
Still an issue in 0.68.2, although I note that WSL now automounts the /mnt/wslg/runtime-dir at /run/user/1000, which saves a peck of trouble. Edited: unless something you do does start a systemd user session, at which point [email protected] blows the contents of that folder and thus /mnt/wslg/runtime-dir away. That's problematic. |
ghost
self-assigned this
|
I could make the user session partially work with native systemd support by providing It gives me running systemd user units and it makes So, YMMV, but it works at least on my system: /etc/wsl.conf |
|
UPD: wsl --shutdown
wsl -u root -- su <username>
ls -al /run/user/1000
total 0
drwx------ 4 username username 120 Nov 30 15:57 .
drwxr-xr-x 4 root root 80 Nov 30 15:57 ..
srw-rw-rw- 1 username username 0 Nov 30 15:57 bus
srw-rw-rw- 1 username username 0 Nov 30 15:57 pipewire-0
drwxr-xr-x 2 username username 60 Nov 30 15:57 pulse
drwxr-xr-x 5 username username 140 Nov 30 15:57 systemdbut when start it normally: wsl --shutdown
wsl -u <username>
ls -al /run/user/1000
total 0
drwx------ 4 username username 120 Nov 30 16:00 .
drwxr-xr-x 3 root root 60 Nov 30 16:00 ..
drwx------ 3 username username 60 Nov 30 16:00 dbus-1
drwx------ 2 username username 80 Nov 30 16:00 pulse
srwxrwxrwx 1 username username 0 Nov 30 16:00 wayland-0
-rw-rw---- 1 username username 0 Nov 30 16:00 wayland-0.lock |
|
I have the same issue. When I install the WSL image (Arch Linux with systemd), on the first login the dbus works correctly and on Then, if I run Then, if I run So, why after |
|
I am noting an additional behavior. From scratch, if I install the WSL image, I get the right |
|
I solved it by running |
|
As I understand the current situation, WSL always tries to set up a user session by running The upshot of this is that on a fast and/or lightly-loaded machine, you always get a user session, but the more heavily loaded your machine is, the more likely it is that this login will go off before systemd is ready for it and you'll get nothing. (Not a problem that can occur on native Linux, of course, since you can't even try to log in until systemd has already passed the relevant startup phase.) Among the various things my hacks do is ensure that no WSL session is started (it wait-loops) before systemd is ready for it. |
|
What is the hack you are describing: "do is ensure that no WSL session is started (it wait-loops) before systemd is ready for it." ? I had the problem starting vscode inside wsl2 (Rocky Linux release 9.1 (Blue Onyx)) requiring /run/user/1000, but that one was missing I do have the /mnt/wsl/run/user/1000, but I do not have /run/user/1000
|
|
Based on the theory that it's a race during startup, starting wsl as root before running my own shell fixes it: |
|
@SvenVD This function: https://github.com/arkane-systems/bottle-imp/blob/master/binsrc/imp/__main__.py#L58-L111 in bottle-imp handles this situation. The first loop (lines 61-78) waits until the system dbus socket is available, because you need the system dbus to query systemd for its state. The second loop (lines 80-103) keep querying systemd as to its state (via https://github.com/arkane-systems/bottle-imp/blob/master/binsrc/imp/helpers.py#L24 ) until it has reached the running state (i.e., all the units are successfully started up). This delay means that when we need to ask systemd to do something - such as when login (via PAM) asks systemd-logind to create a user session, runtime directory, etc., etc., - it's ready to do so. WSL doesn't include this delay natively, so if your computer isn't fast enough to start all the relevant bits of systemd up before it gets around to making a login session, it's not prepared and listening to the instruction to create it, and so you don't get one. |
|
Really need this to run |
|
I have had success working around the wsl pam_env and systemctl --user commands issue by changing the wsl startup command parameters to launch a shell through sudo i.e.
whether or not this will help op with `loginctl enable-linger username' I can not say for sure. |
|
I tackled this problem on the context of the WebKit GTK port building with the following wsl version installed by [08:30] :WebKit (main %) | systemctl status --user
● XXX
State: running
Jobs: 0 queued
Failed: 0 units
Since: Thu 2024-04-18 08:17:10 JST; 13min ago
CGroup: /user.slice/user-1000.slice/[email protected]
└─init.scope
├─413 /lib/systemd/systemd --user
└─414 (sd-pam)
[08:30] XXX:WebKit (main %) | cat /etc/wsl.conf
[boot]
systemd=true and the workaround doesn't work for me. I also tried [09:17] | sudo systemctl restart user@1000
[09:18] | ls -al /run/user/1000
total 0
drwx------ 6 khei4 khei4 220 Apr 18 09:18 ./
drwxr-xr-x 4 root root 80 Apr 18 09:17 ../
drwxr-xr-x 3 khei4 khei4 60 Apr 18 09:17 dbus-1/
prw------- 1 khei4 khei4 0 Apr 18 09:17 fish_universal_variables.notifier|
drwx------ 2 khei4 khei4 140 Apr 18 09:18 gnupg/
srw-rw-rw- 1 khei4 khei4 0 Apr 18 09:18 pk-debconf-socket=
drwxr-xr-x 2 khei4 khei4 80 Apr 18 09:17 pulse/
srw-rw-rw- 1 khei4 khei4 0 Apr 18 09:18 snapd-session-agent.socket=
drwxr-xr-x 5 khei4 khei4 140 Apr 18 09:18 systemd/
lrwxrwxrwx 1 root root 31 Apr 18 09:17 wayland-0 -> /mnt/wslg/runtime-dir/wayland-0=
lrwxrwxrwx 1 root root 36 Apr 18 09:17 wayland-0.lock -> /mnt/wslg/runtime-dir/wayland-0.lock Control pane > programs and features > Turn Windows features on or off Virtual Machine Platform and Windows Subsystem for Linux is tuned on [11:27] X:WebKit (main %) | Tools/Scripts/update-webkitgtk-libs
Ensuring the local Flatpak repository is not corrupted
[19/20] Verifying webkit-sdk:runtime/org.webkit.Platform/x86_64/23.08…
Checking remotes...
Pruning objects
Updating Flatpak environment
Looking for updates…
ID Branch Op Remote Download
1. [✗] org.freedesktop.Platform.GL.default 23.08 i webkit-sdk 1.0 kB / 484.9 MB
Warning: While pulling runtime/org.freedesktop.Platform.GL.default/x86_64/23.08 from remote webkit-sdk: Invalid checksum for static delta 9c2522fc508be5d80b50a7ae93daa626ed23462bb8d374480c92dc937187c401
Installation complete.
SDK version: 277469@main
Updating icecc/sccache standalone toolchain archives
Error connecting: Could not connect: No such file or directory
Failed to get a11y address Command '('gdbus', 'call', '-e', '-d', 'org.a11y.Bus', '-o', '/org/a11y/bus', '-m', 'org.a11y.Bus.GetAddress')' returned non-zero exit status 1.
bwrap: Can't find source path /run/user/1000/bus: No such file or directory
The following command returned a non-zero exit status: flatpak run --user --die-with-parent --filesystem=host --allow=devel --talk-name=org.gtk.vfs --talk-name=org.gtk.vfs.* --device=all --device=dri --share=ipc --share=network --socket=pulseaudio --socket=session-bus --socket=system-bus --socket=wayland --socket=x11 --system-talk-name=org.a11y.Bus --system-talk-name=org.freedesktop.GeoClue2 --talk-name=org.freedesktop.Flatpak --talk-name=org.freedesktop.secrets --env=TEST_RUNNER_INJECTED_BUNDLE_FILENAME=/app/webkit/WebKitBuild/Release/lib/libTestRunnerInjectedBundle.so --env=PATH=/usr/lib/sdk/llvm16/bin:/usr/bin:/usr/lib/sdk/rust-stable/bin/ --env=TZ=America/Los_Angeles --env=WAYLAND_DISPLAY=wayland-0 --env=DISPLAY=:0 --command=/usr/bin/which org.webkit.Sdk gcc
Output: b''
Died at Tools/Scripts/update-webkitgtk-libs line 30. But I finally could see bus by removing the [08:33] | ls -al /run/user/1000
total 0
drwxr-xr-x 12 khei4 khei4 480 Apr 19 07:57 .
drwxr-xr-x 3 root root 60 Apr 18 18:04 ..
drwxr-xr-x 2 khei4 khei4 200 Apr 19 08:05 .dbus-proxy
drwxr-xr-x 4 khei4 khei4 80 Apr 19 08:05 .flatpak
drwx------ 3 khei4 khei4 80 Apr 18 18:49 .flatpak-helper
drwx------ 2 khei4 khei4 60 Apr 18 18:49 at-spi
srw-rw-rw- 1 khei4 khei4 0 Apr 18 18:04 bus
drwxr-xr-x 4 khei4 khei4 80 Apr 18 18:04 dbus-1
drwx------ 2 khei4 khei4 60 Apr 18 18:12 dconf
dr-x------ 2 khei4 khei4 0 Jan 1 1970 doc
drwx------ 2 khei4 khei4 140 Apr 18 18:04 gnupg
srw-rw-rw- 1 khei4 khei4 0 Apr 18 18:04 pipewire-0
-rw-rw---- 1 khei4 khei4 0 Apr 18 18:04 pipewire-0.lock
srw-rw-rw- 1 khei4 khei4 0 Apr 18 18:04 pk-debconf-socket
drwxr-xr-x 2 khei4 khei4 80 Apr 18 18:04 pulse
srw-rw-rw- 1 khei4 khei4 0 Apr 18 18:04 snapd-session-agent.socket
drwxr-xr-x 6 khei4 khei4 160 Apr 18 18:49 systemd
srwxr-xr-x 1 khei4 khei4 0 Apr 19 07:57 vscode-git-12b25b9439.sock
srwxr-xr-x 1 khei4 khei4 0 Apr 18 22:46 vscode-ipc-2f1f8efb-de93-454c-8e94-1f9928d062b2.sock
srwxr-xr-x 1 khei4 khei4 0 Apr 18 22:39 vscode-ipc-8cbd36d5-3b2a-4e02-9b85-4c506b6be3e4.sock
srwxr-xr-x 1 khei4 khei4 0 Apr 19 07:57 vscode-ipc-9a53415a-c39b-4a39-a971-4f12fed57ce9.sock
srwxr-xr-x 1 khei4 khei4 0 Apr 19 07:56 vscode-ipc-b59dd6fe-d8e1-4a6f-af26-4a86ec114c49.sock
lrwxrwxrwx 1 root root 31 Apr 18 18:04 wayland-0 -> /mnt/wslg/runtime-dir/wayland-0
lrwxrwxrwx 1 root root 36 Apr 18 18:04 wayland-0.lock -> /mnt/wslg/runtime-dir/wayland-0.lock |
|
I get the same error when I tried to start a Homebrew service in Ubuntu 22.04 in WSL 2. ❯ brew services start minio --debug
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/brew.rb (Formulary::FromAPILoader): loading minio
/usr/bin/env /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/shims/shared/git --version
==> /home/linuxbrew/.linuxbrew/bin/systemctl --user status homebrew.minio
Failed to connect to bus: No such file or directory
Error: Failure while executing; `/home/linuxbrew/.linuxbrew/bin/systemctl --user daemon-reload` exited with 1.
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/extend/kernel.rb:263:in `safe_system'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Taps/homebrew/homebrew-services/lib/service/services_cli.rb:332:in `install_service_file'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Taps/homebrew/homebrew-services/lib/service/services_cli.rb:112:in `block in start'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Taps/homebrew/homebrew-services/lib/service/services_cli.rb:97:in `each'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Taps/homebrew/homebrew-services/lib/service/services_cli.rb:97:in `start'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Taps/homebrew/homebrew-services/lib/service/commands/start.rb:12:in `run'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Taps/homebrew/homebrew-services/cmd/services.rb:139:in `run'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/brew.rb:92:in `<main>'What's the solution? |
|
A further thing that can apparrently go wrong here, is that systemd --user can create its socket, and then WSLg comes along and overmounts /run/user/1000 ... as I just found out - #10205 for more :-( |
|
Try this solution:
can be fixed by adding these lines to The issue is that when running RStudio, it expects the socket to be located at a fixed path in /run/user/1000/bus, which doesn't work in WSL2 where the socket is instead created as an abstract socket and is found under /tmp |
|
From @cerebrate's solution, I succesfully worked around this issue by setting my terminal to run this as root on startup: zsh -c \
"until [ -S /run/dbus/system_bus_socket ]; \
do sleep 1; \
done; \
systemctl restart user@1000; \
export DBUS_SESSION_BUS_ADDRESS='unix:path=/run/user/1000/bus'; \
exec sudo --preserve-env=DBUS_SESSION_BUS_ADDRESS --user xieve zsh"You can switch out
I also had a simpler solution: zsh -c "until [ -S /run/dbus/system_bus_socket ]; do sleep 1; done; exec login -p -f xieve"This has the significant drawback of resetting
|
This solved it for me! Thank you! |
|
I created an overlay for the |
Version
Windows version: 10.0.22621.521
WSL Version
Kernel Version
5.15.62.1-microsoft-standard-WSL2
Distro Version
ArchWSL
Other Software
Repro Steps
sudo loginctl enable-linger <username>[1]wsl --shutdownExpected Behavior
User
systemdservice should launched.Actual Behavior
User
systemdservice is not launched. Checked via below commands. Neither succeeded.Diagnostic Logs
I noticed that now WSL set below variables correctly.
But then I suppose that this is due to init now handled by
systemd, which is the normal behavior. However, the user (d)bus is not present in the above directory.The text was updated successfully, but these errors were encountered: