I maintain TurboVNC, a modern Xvnc implementation derived originally from TightVNC and TigerVNC, and users have reported this problem both with the Firefox snap on Ubuntu 22.04 and with Podman on Fedora. I wanted to add some clarifying remarks:
- The reason why Linux remote desktop solutions such as TurboVNC call dbus-launch to create a unique session bus instance for each remote desktop session is because, if we don't, we can't have multiple simultaneous remote desktop sessions under the same user account. Granted that GNOME 3+ doesn't seem to officially support multiple simultaneous sessions, but in practice, it mostly works as long as each session has a unique session bus instance. MATE and Xfce fully work with multiple simultaneous sessions (except for cgroup issues like this, which aren't related to the window manager.) - TigerVNC, in v1.11, adopted a completely different approach for launching VNC sessions, using a systemd service that emulates a GDM login. Thus, it is "fully baked" from systemd's point of view and doesn't experience this issue. However, the price you pay is that only root can start/stop VNC sessions, and only one session (including VNC and local sessions) can run simultaneously. Also, this new approach eliminated the ability to use TigerVNC on non-systemd operating systems (FreeBSD) at all. Referring to the tigervnc-users mailing list, it was a somewhat unpopular move, so we have chosen to stick with the traditional (vncserver) approach in TurboVNC. However, it would be really nice if we could figure out how to get what we want (multiple simultaneous sessions under the same user account) without having a "half-baked" desktop. - As near as I can tell, you can get all of the benefits of TigerVNC's approach by simply foregoing the creation of a new session bus instance and using the one that systemd provides, with the caveat that only one session at a time can use the systemd-provided session bus instance. Someone who understands more about systemd than I do will have to tell me whether this is still half-baked (maybe 3/4-baked) or not, but it does eliminate this specific cgroup issue. (Those who care to experiment can use the latest pre-release build of TurboVNC, downloadable from https://turbovnc.org/DeveloperInfo/PreReleases, and set TVNC_SHAREDDBUS=1 in the environment to force a new session to use the systemd-provided session bus instance.) - Setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$UID/bus before launching Firefox, i.e. telling Firefox to use the systemd-provided session bus instance, is a problematic workaround. If another session, such as a local session, is using the systemd-provided session bus instance, then this will cause some of the dialogs in Firefox (for instance, the certificate import dialog) to appear in the other session rather than in the remote desktop session. If there is no session using the systemd-provided session bus instance, then those dialogs will not appear at all. - Unsetting DBUS_SESSION_BUS_ADDRESS as a workaround avoids the aforementioned dialog issues, but I have seen Firefox complain about this, something to the effect of being unable to save something to the D-Bus session. I don't remember the exact error message, and I can't currently reproduce it. tl;dr: It seems like an oversight that systemd won't allow multiple simultaneous remote desktop sessions under the same user account without the sessions being half-baked, and IMHO, this is a competitive disadvantage for Linux vs. Windows (which does support multiple simultaneous remote desktop sessions under the same user account, at least in Windows Server.) Maybe someone can convince me that I'm a pig- ignorant philistine for believing that Linux should have this capability. I don't confess to be anything close to a systemd expert. I just know that our use case used to work perfectly fine, but GNOME 3 started breaking some things with it, and now cgroup v2 is breaking more things with it. So I would love to know how to support our use case in a manner that is blessed by systemd, if such is even possible. (It may not be.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1951491 Title: Can't run snaps: .slice/session-1.scope is not a snap cgroup Status in X2Go: New Status in Xpra Terminal Server: New Status in snapd package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Incomplete Status in x2goserver package in Ubuntu: Confirmed Status in snapd package in Debian: New Status in snapd package in Fedora: New Bug description: I just upgraded from hirsute to impish using do-release-upgrade. On the upgraded system, I can't run either firefox or chromium (both of which worked fine under hirsute). Both fail with: /user.slice/user-NNN.slice/session-1.scope is not a snap cgroup where NNN is my uid With firefox, I was able to fix the problem with: snap remove --purge firefox apt purge firefox apt install firefox Now firefox works. But I tried the same thing substituting chromium- browser for firefox, and it didn't help: chromium fails with the same error message. I guess there must be something left over from the hirsute version of snapd that isn't getting noticed or cleared by the impish version? Someone suggested this might be related to bug 1850667, but that bug is marked fixed as of a couple months ago, and I just did this upgrade today. Also, it doesn't mention the error message I'm seeing. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: snapd 2.53+21.10ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Nov 18 18:12:45 2021 InstallationDate: Installed on 2020-04-29 (568 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: snapd UpgradeStatus: Upgraded to impish on 2021-11-18 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/x2go/+bug/1951491/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
