"not a snap cgroup" error when running Chromium

snap
3

I’m not sure about the specifics, but this has something to do with the way the sessions are made. I’m mildly surprised that neither sudo -iu otherphil nor sudo login followed by logging in as otherphil works, but my own reproduction of this issue on Ubuntu 22.04 went as follows:

  • Using sudo -i or sudo -s: error
  • Using sudo su or sudo su -: error
  • Using sudo login: error

But…

  • sshing to localhost as the other user: Success
  • Switching to another virtual terminal and logging in as the other user: Success

Setting SNAPD_DEBUG=1, I see that an SSH session puts the process into the correct cgroup, whereas sudo -i doesn’t.

When I use ssh, then loginctl list-sessions shows two sessions (one for myself and one for my test user). However, sudo and su (even sudo login) don’t create a session.

You can get a similar control group issue by suing into that user and running systemd --user:

$ systemd --user
Failed to create /user.slice/user-1000.slice/user@1000.service/app.slice/dbus.service/init.scope control group: Permission denied
Failed to allocate manager object: Permission denied

So it appears that even after suing we’re still in the same user-1000 systemd slice. (Running sleep 100 from that other user’s terminal and then loginctl user-status confirms this, as I can see that sleep process under my own user). Likewise, SSHing in creates a new user-1001 slice. (You can SSH in and then try loginctl user-status otherphil to see that slice).

I’m not familiar enough with how systemd handles sessions, seats, etc. to figure it out, but hopefully the ssh workaround is sufficient for you!

1 Like