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 <email address hidden>
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
>
>
it is more that systemd is not setup properly rather than snaps, but snaps BUS_ADDRESS is supposed to be set in the login process,
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_
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 <email address hidden>
wrote:
> Some clues: unit=multi- TYPE=wayland dbus-run-session gnome-session` then BUS_ADDRESS gets set to something like BUS_ADDRESS= unix:abstract= /tmp/dbus- guid=b86aac9a59 f39dddad072fc86 546c3f8" and the Firefox snap slice/user- 1000.slice/ session- 1.scope is not a snap BUS_ADDRESS= "unix:path= $XDG_RUNTIME_ DIR/bus" firefox` from BUS_ADDRESS is already set in the non-graphical /bugs.launchpad .net/bugs/ 1951491 session- 1.scope is not a snap cgroup /bugs.launchpad .net/x2go/ +bug/1951491/ +subscriptions
>
> If I start Ubuntu 22 with kernel argument `systemd.
> user.target` (i.e. non-graphical) then start Wayland with
> `XDG_SESSION_
> DBUS_SESSION_
> "DBUS_SESSION_
> mcSf5L11K8,
> errors with "/user.
> cgroup".
>
> But Firefox launched with
> `DBUS_SESSION_
> a Terminal will run.
>
> Note that DBUS_SESSION_
> 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:/
>
> Title:
> Can't run snaps: .slice/
>
> To manage notifications about this bug go to:
> https:/
>
>
--
Tim Richardson