podman containers fail to start through TurboVNC session

[antoniotorresm]

When trying to run a podman container inside a session created by TurboVNC, the following happens:

✘-126 13:32 ~ $ podman run hello-world
Error: OCI runtime error: crun: sd-bus call: Process org.freedesktop.systemd1 exited with status 1: Input/output error
✘-126 13:36 ~ $ 

Log in system output:

Jan 16 13:36:16 localhost.localdomain podman[9396]: 2024-01-16 13:36:16.604144378 +0100 CET m=+0.046245165 container create 6b4ed25962528bfd0bbc347b393b33d2f18a489aa6d39ce1a6d771d49ef057ec (image=quay.io/podman/hello:latest, name=vigilan>
Jan 16 13:36:16 localhost.localdomain dbus-daemon[5628]: [session uid=1000 pid=5617] Activating service name='org.freedesktop.systemd1' requested by ':1.97' (uid=1000 pid=9396 comm="podman run hello-world" label="unconfined_u:unconfined_>
Jan 16 13:36:16 localhost.localdomain dbus-daemon[5628]: [session uid=1000 pid=5617] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
Jan 16 13:36:16 localhost.localdomain dbus-daemon[5628]: [session uid=1000 pid=5617] Activating service name='org.freedesktop.systemd1' requested by ':1.97' (uid=1000 pid=9396 comm="podman run hello-world" label="unconfined_u:unconfined_>
Jan 16 13:36:16 localhost.localdomain dbus-daemon[5628]: [session uid=1000 pid=5617] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
Jan 16 13:36:16 localhost.localdomain dbus-daemon[5628]: [session uid=1000 pid=5617] Activating service name='org.freedesktop.systemd1' requested by ':1.99' (uid=1000 pid=9426 comm="/usr/bin/crun --systemd-cgroup --log-format=json -" lab>
Jan 16 13:36:16 localhost.localdomain dbus-daemon[5628]: [session uid=1000 pid=5617] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
Jan 16 13:36:16 localhost.localdomain dbus-daemon[5628]: [session uid=1000 pid=5617] Activating service name='org.freedesktop.systemd1' requested by ':1.99' (uid=1000 pid=9426 comm="/usr/bin/crun --systemd-cgroup --log-format=json -" lab>
Jan 16 13:36:16 localhost.localdomain dbus-daemon[5628]: [session uid=1000 pid=5617] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
Jan 16 13:36:16 localhost.localdomain conmon[9425]: conmon 6b4ed25962528bfd0bbc <nwarn>: runtime stderr: sd-bus call: Process org.freedesktop.systemd1 exited with status 1: Input/output error
Jan 16 13:36:16 localhost.localdomain conmon[9425]: conmon 6b4ed25962528bfd0bbc <error>: Failed to create container: exit status 1

If I try to execute the same in the physical session, the container starts just fine. I'm testing in Fedora 39.

[antoniotorresm]

It works fine with --cgroups=disabled:

✔ 13:49 ~ $ podman run --cgroups=disabled hello-world
!... Hello Podman World ...!

         .--"--.           
       / -     - \         
      / (O)   (O) \        
   ~~~| -=(,Y,)=- |         
    .---. /`  \   |~~      
 ~/  o  o \~~~~.----. ~~   
  | =(X)= |~  / (O (O) \   
   ~~~~~~~  ~| =(Y_)=-  |   
  ~~~~    ~~~|   U      |~~ 

Project:   https://github.com/containers/podman
Website:   https://podman.io
Documents: https://docs.podman.io
Twitter:   @Podman_io

In any case, the issue is related to TurboVNC, as it doesn't happen in the physical session.

[dcommander]

There's a long discussion here regarding the same issue with confined snap applications under Ubuntu 22.04. tl;dr: You can work around it by unsetting DBUS_SESSION_BUS_ADDRESS before running the application. TurboVNC cannot use the shared D-Bus session bus instance created by systemd, because that would prevent multiple TurboVNC sessions (or a TurboVNC session and a local session) from running simultaneously under the same user account. Thus, each TurboVNC session creates an independent D-Bus session bus instance. However, certain applications don't like that (it may have something to do with cgroups), so it is necessary to unset DBUS_SESSION_BUS_ADDRESS to allow those applications to use the shared D-Bus session bus instance. The only other option would be for us to do what TigerVNC does and use the shared D-Bus session bus instance for the whole VNC session, which would limit us to one simultaneous session. I would personally prefer to retain TurboVNC's multi-session functionality and apply the aforementioned workaround just for the specific applications that need it. However, I would also be open to adding a "shared D-Bus" configuration parameter to TurboVNC, for users who care more about things "just working" in the TurboVNC session than they care about multi-session functionality. Maybe someone who understands systemd and cgroups better than I do can figure out a way to achieve both goals, but at the moment, they seem mutually exclusive to me.

[dcommander]

Refer also to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491?comments=all

Basically cgroup v2 relies on some systemd mumbo-jumbo that is only available through the systemd-created D-Bus session bus instance, but remote desktop software can't use the systemd-created D-Bus session bus instance without being limited to a single session.

I'll spare you my full rant about how Linux distributors need to stop doubling down on the myth that Linux will ever be a popular desktop platform, acknowledge that it is mainly a server platform, and lean into multi-session remote desktop functionality. Windows servers can handle multiple remote desktop sessions under the same user account. Linux servers should as well. But that's going to require revisiting some things vis-a-vis systemd, D-Bus, GNOME, etc.

[dcommander]

https://github.com/TurboVNC/turbovnc/commit/32dd16ff2fe4fce8f2b36f635b0e53c693a1a33d adds an undocumented environment variable (TVNC_SHAREDDBUS) that, when set to 1, will cause the TurboVNC session to use the shared (systemd-provided) D-Bus session bus instance rather than a unique D-Bus session bus instance. Using the shared D-Bus session bus instance should fix all of the incompatibilities with cgroup v2, with the understanding that only one session (including TurboVNC sessions and local sessions) can simultaneously use the shared D-Bus session bus instance.