When starting snap applications via the shell, log messages like the following are produced:
Mar 21 18:07:49 MGLT-Ubuntu chromium_chromium.desktop[13099]: /user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-chromium_chromium-13099.scope is not a snap cgroup
This error is triggered in snapd’s device-cgroup-support.c, where it expects the process to be in a cgroup created by snapd but finds it in an app-gnome-*.scope cgroup instead. I think this is down to a race condition between gnome-shell and snapd.
On the gnome-shell side, it’s doing:
spawns the app via GLib.spawn_async, which returns the pid of the running child process.
Calls GnomeDesktop.start_systemd_scope on the pid.
start_systemd_scope calls the systemd StartTransientUnit D-Bus method to move the pid to the app-gnome-*.scope cgroup.
On the snap side:
the executables in /snap/bin are equivalent to running snap run snapname.
the snap run code asks systemd to move its own pid to a snap.*.scope cgroup via StartTransientUnit.
it then execs /usr/lib/snapd/snap-confine to set up the sandbox. This includes the device-cgroup-support.c code with the cgroup check.
if it could set up the sandbox correctly, snap-confine execs the sandboxed application.
I think the problem occurs if gnome-shell’s StartTransientUnit call occurs between steps (2) and (3) on the snap side.
Sharing debug details from jamesh
When starting snap applications via the shell, log messages like the following are produced: chromium. desktop[ 13099]: /user.slice/ user-1000. slice/user@ 1000.service/ app.slice/ app-gnome- chromium_ chromium- 13099.scope is not a snap cgroup
Mar 21 18:07:49 MGLT-Ubuntu chromium_
This error is triggered in snapd’s device- cgroup- support. c, where it expects the process to be in a cgroup created by snapd but finds it in an app-gnome-*.scope cgroup instead. I think this is down to a race condition between gnome-shell and snapd.
On the gnome-shell side, it’s doing:
spawns the app via GLib.spawn_async, which returns the pid of the running child process.
Calls GnomeDesktop. start_systemd_ scope on the pid.
start_ systemd_ scope calls the systemd StartTransientUnit D-Bus method to move the pid to the app-gnome-*.scope cgroup.
On the snap side:
the executables in /snap/bin are equivalent to running snap run snapname.
the snap run code asks systemd to move its own pid to a snap.*.scope cgroup via StartTransientUnit.
it then execs /usr/lib/ snapd/snap- confine to set up the sandbox. This includes the device- cgroup- support. c code with the cgroup check.
if it could set up the sandbox correctly, snap-confine execs the sandboxed application.
I think the problem occurs if gnome-shell’s StartTransientUnit call occurs between steps (2) and (3) on the snap side.