systemd user session issue with AlmaLinux 9

[csaket]

Version

Microsoft Windows [Version 10.0.22623.875]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.15.68.1-microsoft-standard-WSL2

Distro Version

AlmaLinux 9

Other Software

wsl

PS C:\Users\abc22> wsl --version
WSL version: 0.70.5.0
Kernel version: 5.15.68.1
WSLg version: 1.0.45
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22623.875

.wslconfig

[wsl2]
kernelCommandLine = cgroup_no_v1=cpuset,cpu,cpuacct,io,devices,freezer,net_cls,perf_event,net_prio,hugetlb,pids,rdma

wsl.conf

❯ cat /etc/wsl.conf
[boot]
systemd=true

podman 4.1.1

Repro Steps

podman info reports this issue.

❯ podman info
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available
WARN[0000] For using systemd, you may need to login using an user session
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root)
WARN[0000] Falling back to --cgroup-manager=cgroupfs

systemctl --user status reports error.

❯ systemctl --user status
Failed to connect to bus: No such file or directory

Ubuntu 22.04 has no such issues.

❯ podman info
host:
  arch: amd64
  buildahVersion: 1.23.1

❯  systemctl --user status
● MYLT2022
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2022-11-03 11:14:12 CDT; 3s ago
   CGroup: /user.slice/user-1000.slice/user@1000.service
           ├─user.slice
           │ └─podman-1194.scope
           │   └─1194 /usr/bin/podman --log-level=info system service

Expected Behavior

podman to function correctly

Actual Behavior

user session and dbus errors.

Diagnostic Logs

No response

[elsaco]

@csaket for some (unknown to me) reason user@1000.service is not being started on AL9. The clue is from your podman info output: there is no systemd user session available

You might try starting this service after AL9 instance is running, as a quick workaround until a fix is provided.

Sample output:

[tux@eleven:~]$ systemctl --user status
Failed to connect to bus: No such file or directory

[tux@eleven:~]$ systemctl status user@1000.service
○ user@1000.service - User Manager for UID 1000
     Loaded: loaded (/usr/lib/systemd/system/user@.service; static)
     Active: inactive (dead)
       Docs: man:user@.service(5)

[tux@eleven:~]$ sudo systemctl start user@1000.service

[tux@eleven:~]$ systemctl status user@1000.service
● user@1000.service - User Manager for UID 1000
     Loaded: loaded (/usr/lib/systemd/system/user@.service; static)
     Active: active (running) since Thu 2022-11-03 12:57:28 PDT; 1s ago
       Docs: man:user@.service(5)
   Main PID: 86 (systemd)
     Status: "Ready."
     Memory: 2.6M
     CGroup: /user.slice/user-1000.slice/user@1000.service
             └─init.scope
               ├─86 /usr/lib/systemd/systemd --user
               └─87 "(sd-pam)"

Nov 03 12:57:28 eleven systemd[86]: Reached target Timers.
Nov 03 12:57:28 eleven systemd[86]: Starting D-Bus User Message Bus Socket...
Nov 03 12:57:28 eleven systemd[86]: Starting Create User's Volatile Files and Directories...
Nov 03 12:57:28 eleven systemd[86]: Finished Create User's Volatile Files and Directories.
Nov 03 12:57:28 eleven systemd[86]: Listening on D-Bus User Message Bus Socket.
Nov 03 12:57:28 eleven systemd[86]: Reached target Sockets.
Nov 03 12:57:28 eleven systemd[86]: Reached target Basic System.
Nov 03 12:57:28 eleven systemd[86]: Reached target Main User Target.
Nov 03 12:57:28 eleven systemd[86]: Startup finished in 21ms.
Nov 03 12:57:28 eleven systemd[1]: Started User Manager for UID 1000.

[tux@eleven:~]$ systemctl --user status
● eleven
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2022-11-03 12:57:28 PDT; 5s ago
   CGroup: /user.slice/user-1000.slice/user@1000.service
           └─init.scope
             ├─86 /usr/lib/systemd/systemd --user
             └─87 "(sd-pam)"

and podman info:

[tux@eleven:~]$ podman info
WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers
host:
  arch: amd64
  buildahVersion: 1.26.2
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  ...

[csaket]

That workaround "works" thanks

[cerebrate]

systemd support currently doesn't start user sessions because systemd sessions (and login sessions in general) depend on pam_systemd(8), and thus entering through one of the routes (login, sshd, etc.) that invokes PAM. Since WSL just starts processes inside the instance as the relevant user, PAM isn't invoked, and the systemd user session (and other login-session related things) aren't started up.

In short, this is a variant of #8842 .

(Unfortunately, there are a variety of complications that can come with manually starting a systemd user session dependent on your version of WSL, such as #8918, #8886, #8846, #9025, etc. to take into account. This is where I'm going to toot my own horn, because this is the bunch of stuff arkane-systems/bottle-imp was built to fix, and whether or not you want to use it, the source should demonstrate how to work around all the above in your own solution.)

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!