"not a snap cgroup" error when running Chromium

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