Why podman needs dbus-user-session?

[abitrolly]

Description

In #12983 (comment) dbus-user-session is needed to silence these podman warnings.

$ podman version
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    
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    
Version:      3.0.1
API Version:  3.0.0
Go Version:   go1.15.15
Built:        Thu Jan  1 00:00:00 1970
OS/Arch:      linux/amd64

As I understand D-Bus is a desktop thing, and I am not planning to run any desktop apps on the remote server, so why do I need it to use podman?

Steps to reproduce the issue:

1. Get Debian 11 server
2. apt install podman
3. podman version

[rhatdan]

Podman defaults to working with systemd for setting up cgroups and logging. You can change your cgroup-manager and log-driver settings, and events log to cgroupfs, k8s-file, and file in containers.conf and that should remove the warnings.

[abitrolly]

It already reinvented sd-bus, so why stop there.

[abitrolly]

$ systemctl --user status podman
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

Looks like this systemd integration doesn't work under sudo.

[rhatdan]

You are not in a full login session.

[abitrolly]

What does it mean? There is a separate user to run unprivileged container, without SSH access, so I do sudo su serviceuser -l to login to it. I can run podman run --rm docker.io/hello-world with it successfully, but docker-compose fails.

$ DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock docker-compose up
[+] Running 0/1
 ⠋ Container hello  Creating                                                                                                                                         0.1s
Error response from daemon: network connect is not enabled for rootless containers

$ cat docker-compose.yaml 
version: '3.3'
services:
    hello:
        container_name: hello
        image: docker.io/hello-world

And troubleshooting through systemd as above fails too.

[eriksjolund]

systemd provides some alternatives to using su:

• systemctl --user -M
• systemd-run --user -M
• machinectl shell username@

Here are some examples (run on a Fedora 35 computer)

non-interactively

su

$ sudo useradd test1
$ sudo su - test1 -c "systemctl --user is-system-running"
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

systemctl -M

$ sudo useradd test2
$ sudo systemctl --user -M test2@ is-system-running
running

systemd-run

(I'm not quite sure how this one differs from the previous example systemctl -M )

$ sudo useradd test3
$ sudo systemd-run --machine=test3@ --quiet --user --collect --pipe --wait systemctl --user is-system-running
running

interactively

su

$ sudo useradd test4
$ sudo -iu test4   
[test4@asus ~]$ systemctl --user is-system-running
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
[test4@asus ~]$ exit
$                                                                                                                                                                                   

machinectl

$ sudo useradd test5
$ sudo machinectl shell test5@
Connected to the local host. Press ^] three times within 1s to exit session.
[test5@asus ~]$ systemctl --user is-system-running
running
[test5@asus ~]$ exit
$                                                                                                                                                                             

Quote from systemd/systemd#7451 (comment) :
"su" is a tool for changing user identities and very few other process credentials temporarily. It's not a tool for opening a completely new login session.

[dontlaugh]

We encountered this because we run CI agents in LXD containers, and build podman containers on those agents. It's containers in containers, and we rarely have a "proper" login shell.

Our environment is Ubuntu 21.10, and dbus-user-session was pre-installed; The warning messages were helpful. loginctl enable-linger 2000 and a reboot fixed the problem, for now.