it is more that systemd is not setup properly rather than snaps, but snaps assume systemd cgroup is set up when other applications are not so fussy. systemd-oomd also relies on cgroups and I wonder if it is broken too. Anyway, the root cause of this is not snaps, but rather, snaps expose a bug which has occurred before the graphical session even starts. The DBUS_SESSION_BUS_ADDRESS is supposed to be set in the login process, way before the graphical session starts,,so my own amateur investigations agree with yours. There is a promise relating to the systemd "pam" login steps which do this, and I guess our broken logins skip this, but there are so many scripts involved that it hard to work out. It seems plausible that this is relatively recent change to the login process which old tools with custom login approaches have not been adapted to This is why I concluded that the problem that people are having is related to the way the login is done by their remote access tool, be it nomachine in my case or x2go or the vnc connections that first spawn a login (some types of remote access simply connect to an existing session and these would be immune from our problem). However, I'm just repeating myself, and likewise I will no doubt get more angry replies from people who believe this is a snap bug and are frustrated about the snap developers ignoring it.
On Sun, 5 Nov 2023 at 09:55, Richard Brooksby <1951...@bugs.launchpad.net> wrote: > Some clues: > > If I start Ubuntu 22 with kernel argument `systemd.unit=multi- > user.target` (i.e. non-graphical) then start Wayland with > `XDG_SESSION_TYPE=wayland dbus-run-session gnome-session` then > DBUS_SESSION_BUS_ADDRESS gets set to something like > "DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus- > mcSf5L11K8,guid=b86aac9a59f39dddad072fc86546c3f8" and the Firefox snap > errors with "/user.slice/user-1000.slice/session-1.scope is not a snap > cgroup". > > But Firefox launched with > `DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" firefox` from > a Terminal will run. > > Note that DBUS_SESSION_BUS_ADDRESS is already set in the non-graphical > shell before starting the Wayland session. It is overriden by dbus-run- > session (as documented in the man page). > > I don't understand these systems, but it would seem to me that the > Firefox snap is assuming that it's being run from a top-level session. > If a Wayland is started by a user with dbus-run-session then it can't > talk to it because it's assuming the top level D-bus. > > This might also be a clue as to why things don't work for remote > sessions. Perhaps snaps assume (indirectly) that they're only being run > in a top-level local session. A "standard session" if you like. > > Incidentally, the Firefox is happy if I use `startx` to get a session. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1951491 > > Title: > Can't run snaps: .slice/session-1.scope is not a snap cgroup > > To manage notifications about this bug go to: > https://bugs.launchpad.net/x2go/+bug/1951491/+subscriptions > > -- Tim Richardson -- 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
