2

I started a shell for another user on my system. However there's no systemd user instance for that user:

helloer@host $ sudo -u testusr bash
testusr@host $ systemctl --user status
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

How can I start a dbus or systemd user instance for testusr?

I'm running Arch Linux, linux 5.11.8.arch1-1, dbus 1.12.20-1, systemd 247.4-2.

Helloer
  • 123
  • 4
  • Would `eval $(dbus-launch --sh-syntax)` help? – Jiri B Mar 25 '21 at 22:53
  • Maybe... After your command, `systemctl status --user` says: `Failed to read server status: Process org.freedesktop.systemd1 exited with status 1` – Helloer Mar 26 '21 at 00:44
  • Not even root can do what your asking. – Cinaed Simson Mar 26 '21 at 01:48
  • On Debian 10, in the command systemctl --user status the --user is the owner of /run/user/"uid", i.e., the user logged into the console. – Cinaed Simson Mar 26 '21 at 02:11
  • Does this answer your question? https://unix.stackexchange.com/a/615964/272848 – Stewart Mar 26 '21 at 11:06
  • @Stewart the answer just restates the problem. The only advice seemingly useful in the context of this question is one about `machinectl`, but running a `machinectl login archie` on my distro results in a `Failed to get login PTY: No machine 'archie' known`, and from looking at man it mentions something about containerization, so I presume it is completely irrelevant to the issue. – Hi-Angel Apr 10 '23 at 11:48

2 Answers2

1

If you want to do systemd stuff for another user, the simplest thing is to login as that user, eg with ssh user@localhost, but here is the minimal setup alternative to get a user slice running bash:

otheruser=testusr
id=$(id -u $otheruser)
sudo mkdir -p /run/user/$id
sudo chown $otheruser /run/user/$id
sudo systemctl start user@$id
sudo -u $otheruser \
 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$id/bus \
 systemd-run --user --scope /bin/bash
meuh
  • 49,672
  • 2
  • 52
  • 114
1

Per the systemd devs:

"su" is a tool for changing user identities and very few other process credentials temporarily. It's not a tool for opening a completely new login session. A new login session has a very well defined, pristine setup, not inheriting anything from any other session, but this is really not the case for "su" uid changes: most of the execution environment is inherited over, in numerous and non-obvious ways, for example MAC contexts, audit contexts, cgroup contexts, namespace contexts, scheduling, timer granularity,

You'll need to login as your user via the TTY, your display manager, machinectl login or ssh to get a session that is clean enough to run the systemd user bus.

If none of these make sense for your user, then perhaps your user is a system user (not intended for login). In that case, consider using User= in your service instead of trying to run this on the user bus.

Stewart
  • 12,628
  • 1
  • 37
  • 80