Comment 13 for bug 2011806

Revision history for this message
Sebastien Bacher (seb128) wrote :

Sharing debug details from jamesh

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.