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
orsudo -s
: error - Using
sudo su
orsudo su -
: error - Using
sudo login
: error
But…
-
ssh
ing tolocalhost
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 su
ing 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 su
ing 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!