1

I log in wish SSH as one user "Ubuntu" on a server. I however want to manage run some systemd services as another user "ABC".

If I try to sudo -u abc bash as user ABC then every systemd --user command gives the error:

Failed to connect to bus: No medium found

I found this thread which suggested adding the following to ~/.bashrc:

export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

This changes the error to:

Failed to connect to bus: No such file or directory

Other sources suggested that headless servers don't normally have dbus installed so this makes sense (it appears to be a component of x11). Though I don't know why it works without issue if I run it as ubuntu.

I found this Suggested Workaround

sudo systemctl -M abc@ --user restart foobar.service

This works for basic start, stop, status but:

  • systemctl --user cat doesn't work
  • No variation of journalctl seems to work:
Failed to open root directory of machine 'abc@': The name org.freedesktop.machine 1 was not provided by any .service files
Failed to open journal: No route to host
  • It is just very long to type and inconvenient.

I really just want a shell for this other user just like when I log into ubuntu and can manage all my user services with no issue.

I mention Podman because Podman also is really unhappy when I run it as a different user. It works fine if I use it as ubuntu but get erors if I run it with sudo -u. Like systemd I have some partial workarounds but none seem to work well.

Improve this question

4 Answers 4

Reset to default
3

Use machinectl shell to immediately get a "full" shell for another user on the same host.

machinectl shell
Using the shell command without arguments (thus invoking the executed shell or command on the local host), is in many ways similar to a su(1) session, but, unlike su, completely isolates the new session from the originating session, so that it shares no process or session properties and is in a clean well-defined state. It will be tracked in a new utmp, login, audit, security, and keyring sessions, and will not inherit any environment variables or resource limits, among other properties.

Machine and Image Names
A special machine with the name ".host" refers to the running host system itself. This is useful for execution operations or inspecting the host system as well.

# NOTE: enter new instance of default SHELL of anotheruser.
sudo machinectl shell [email protected]

This shell instance works well for:

  • Interacting with systemctl --user commands/units, journalctl --user logs, rootless/per-user podman containers/pods/kubes/networks/secrets/quadlets, and so forth.
  • Performing system administration tasks in a clean root user shell.

On Debian-based systems machinectl is part of the systemd-container package.

Improve this answer
0

One major point to start with: D-Bus is not a singleton. The exact same software is used in several different configurations to provide several distinct "buses" for different purposes: a global 'system' bus, a per-user 'session' bus, others as needed. Anything you do with D-Bus needs to be qualified with which bus is involved, as otherwise you will end up with nonsensical fixes (e.g. dbus-launch starts a session bus and is irrelevant if the program needs a system bus, whereas /etc/init.d/dbus starts the system bus and is irrelevant if the program needs a session bus).

From what you've described in your post, it seems that a per-user Podman setup expects a session bus to be present.

  • The session bus can be started in several ways including manually, but by default one is started by systemd when the user logs in.

  • Technically, a "custom" session bus can also be started with 'dbus-run-session' or 'dbus-launch' or even manual 'dbus-daemon' invocation, though I suspect that's not enough for podman; it likely will also expect systemd to be available on the bus as well, in which case you really need the "login" as that starts both a per-user systemd and a per-user D-Bus.

Second point: It is not about the shell whatsoever, but about the user switching mechanism. Merely changing your UID using su or sudo does not count as a 'login' in this sense; even though the new shell is running under user B (and might have loaded user B's ~/.profile and such), all of it is still grouped under the login session of user A.

The mechanism for this is the PAM module pam_systemd, which is run as part of the CLI/SSH/GUI login procedure to register a "login" with systemd – but it is not run as part of sudo/su, and not actually allowed to register a "login" from within an already existing one; it needs to be done fresh.

  • If you want to imitate a login, use machinectl shell foouser@ (on second thought I'm not entirely sure if this works – I think I got it mixed up with machinectl login – but still, it has a much higher chance of working due to the aforementioned 'fresh invocation' reason).

    (The newer run0 --user=foouser might also work, although I recall a mailing list thread about it having some bugs related to PAM.)

  • If all you want is to start user-level services, then systemctl --user -M foouser@ is a correct way to do it "from outside".

    Related: If you want to start one-off things that don't have a service definition, use systemd-run --user (which accepts the same -M if needed to use from outside).

  • If you want to force systemd to start its user-level stuff for a specified user without there being any login for that user, run loginctl enable-linger foouser as root.

    Doing this will allow you to manually export XDG_RUNTIME_DIR= etc= from any kind of shell if you want. (This didn't work in your original attempt because it wasn't the lack of environment variables that was the problem – it was the lack of actual D-Bus socket that the variables point to.) Although this is automated by the -M user@ option of systemctl and systemd-run.

(No, the concept of "login shell" as in su - doesn't have anything to do with this.)

Improve this answer
-1

If I try to sudo bash as user ABC then every systemd --user command gives the error:

Failed to connect to bus: No medium found

Yes, there's no user session (of user ABC), so there's no session bus to connect to. Makes sense to me!

Not gonna comment on a solution you copied that starts with "this solution is deprecated…". It's right, that solution is not a solution.

Other sources suggested that headless servers don't normally have dbus installed so this makes sense.

That must have been 20 years ago… usually, modern Linux systems do have dbus installed. Anything with systemd on it definitely has.

I mention Podman because Podman also is really unhappy when I run it as a different user. Like systemd I have some partial workarounds but none seem to work well.

One of Podman's primary reasons to exist is that that is not true. You should probably fix that problem, not find workarounds stacked on workarounds.

I have multiple servers where I start podman pods with multiple containers at boot as separate, non-root users using systemd service scripts, which podman even has a command to create… so, that's definitely fixable. You should probably ask a new question! Probably you're just missing something that's far easier to fix than to figure out whether, and if, where, a non-login process can find the dbus user session bus if started at all.

Improve this answer
6
  • 1
    Thanks for the answer. You are basically telling me why the solutions I tried don't work, which is somewhat helpful but I also already know they don't work. To answer the question would mean including something that would work. Commented Oct 21, 2024 at 6:12
  • Well, the answer is: the thing that will work is using podman as user, but you don't tell us how that fails, so I can't tell you how to solve that. Commented Oct 21, 2024 at 10:05
  • I can find quite a few sources suggesting systemd does not work via sudo, it's not just a me problem. Just none of the solutions seem to work Commented Oct 21, 2024 at 10:28
  • again, I have told you what's the problem with the way you're approaching this in my answer, I can't comment on sources that you can't find. It wouldn't really matter, anyways: solve the issue you have with podman, then you won't have to solve this (non-)issue; your problems wholly come from the fact that you're doing something architecturally unusual, and probably (I can't know that) contrary to systemd's design. Commented Oct 21, 2024 at 10:31
  • I can work around the issue with podman, and I can workaround the issue with systemd. The workaround for sytemd has the problems listed above, the workaround for podman works fine I just think it should not be nececairy if I managed to create a "normal" shell. I know I'm probably doing something arcitecturally unsound but I'm not sure what the correct "sound" way is. Commented Oct 21, 2024 at 10:49
-1 
sudo bash

by default gives you a shell running as the root user. Once you have root permissions, you can use other tools to launch an interactive session as the ABC user. For example, if the ABC user has been assigned a normal interactive shell and has a normal home directory:

su - ABC

will give you a session (shell) as if you had just logged in as the ABC user. Now the commands you type will have the permissions of the ABC user. Typing 'exit' will return to the shell running as the root user, and another exit command will return you to the shell running as your account.

Should podman commands be sensitive to which user invokes them? In theory no, but often applications are configured to run under one particular Linux user. Trying to start/stop/manage the application as a different user will encounter problems. Usually, however, documentation will be left behind on how to log into your own (different) account on the server and then switch to the application's account before running the application commands.

Improve this answer
2
  • podman should 100% be sensitive to which user invokes it — that's a main feature of podman, per-user configuration, user-executed containers (as opposed to central configuration for the docker daemon, and execution of containers by that). Commented Oct 21, 2024 at 10:06
  • 1
    Quote: you cannot use sudo and su with rootless containers from: redhat.com/en/blog/sudo-rootless-podman Commented Oct 21, 2024 at 19:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.