podman containers fail to start through TurboVNC session about turbovnc HOT 4 CLOSED

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.

from turbovnc.

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.

from turbovnc.

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.

from turbovnc.

32dd16f 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.

from turbovnc.