我以“Ubuntu”用户身份登录 SSH 到服务器上。但是我想以另一个用户“ABC”身份管理运行一些 systemd 服务。
如果我尝试sudo -u abc bash以用户身份执行此操作ABC，则每个systemd --user命令都会出现错误：
Failed to connect to bus: No medium found
我发现这个线程建议添加以下内容~/.bashrc：
export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
这会将错误更改为：
Failed to connect to bus: No such file or directory
其他消息来源表明，无头服务器通常不会安装 dbus，因此这是有道理的（它似乎是 x11 的一个组件）。虽然我不知道为什么如果我将其作为 运行，它会毫无问题地运行ubuntu。
我发现这个建议的解决方法
sudo systemctl -M abc@ --user restart foobar.service
这对于基本start、stop有效，status但是：
systemctl --user cat不起作用- 似乎没有任何变化
journalctl有效：
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
- 打字太长，不方便。
我真的只是想要一个这个其他用户的 shell，就像我登录时一样，ubuntu并且可以毫无问题地管理我的所有用户服务。
我提到 Podman 是因为当我以其他用户身份运行 Podman 时，它也会非常不高兴。如果我以 身份使用它，它会正常工作，ubuntu但如果我以 运行它，就会出错sudo -u。像 systemd 一样，我有一些部分解决方法，但似乎都没有效果好。
首先要说明的一个要点是：D-Bus 不是单例。完全相同的软件可用于多种不同的配置，以提供用于不同目的的多种不同的“总线”：全局“系统”总线、每个用户的“会话”总线，以及其他根据需要提供的总线。使用 D-Bus 进行的任何操作都需要限定所涉及的总线，否则您将得到毫无意义的修复。
根据您在帖子中描述的内容，似乎每个用户的 Podman 设置都需要会话总线存在。
会话总线可以通过多种方式启动，包括手动启动，但默认情况下，当用户登录时由 systemd 启动。
从技术上讲，“自定义”会话总线也可以通过“dbus-run-session”或“dbus-launch”或甚至手动“dbus-daemon”调用来启动，尽管我怀疑这对 podman 来说还不够；它可能还会期望 systemd 也在总线上可用，在这种情况下你确实需要“登录”，因为它会启动每个用户的 systemd和每个用户的 D-Bus。
第二点：这与 shell 无关，而是与用户切换机制有关。仅使用
su或更改sudoUID 并不算作“登录”；即使新 shell 在用户 B 下运行（并且可能已加载用户 B 的 ~/.profile 等），但所有内容仍归属于用户 A 的登录会话。实现此目的的机制是 PAM 模块
pam_systemd，它作为 CLI/SSH/GUI 登录过程的一部分运行，以使用 systemd 注册“登录名” - 但它不作为 sudo/su 的一部分运行，并且实际上不允许从已经存在的登录名中注册“登录名”；它需要重新完成。如果您想模拟登录，请使用
machinectl shell foouser@。（较新的版本
run0 --user=foouser可能也能工作，尽管我记得有一个邮件列表主题说它存在一些与 PAM 相关的错误。）如果您想要的只是启动用户级服务，那么
systemctl --user -M foouser@“从外部”执行此操作是正确的方法。相关：如果您想启动没有服务定义的东西，请使用（如果需要从外部使用，
systemd-run --user则接受相同的服务）。-M如果您想强制 systemd 为指定用户启动其用户级别的功能，而无需该用户登录，请
loginctl enable-linger foouser以 root 身份运行。如果您愿意，这样做将允许您手动执行
export XDG_RUNTIME_DIR=等等。（这在您最初的尝试中不起作用，因为问题不是缺少环境变量，而是缺少变量指向的实际 D-Bus 套接字。）尽管这是通过-M user@systemctl 和 systemd-run 选项自动完成的。（不，“登录 shell”的概念与
su -此无关。）是的，没有用户会话（用户 ABC 的会话），因此没有会话总线可以连接。我觉得这很合理！
不会对你复制的以“此解决方案已弃用…”开头的解决方案发表评论。没错，那个解决方案不是解决方案。
那肯定是 20 年前的事了……通常，现代 Linux 系统都会安装 dbus。任何带有 systemd 的东西肯定都安装了。
Podman 存在的主要原因之一就是这种说法并不正确。你应该解决这个问题，而不是寻找一堆堆的变通方法。
我有多个服务器，在这些服务器上，我使用 systemd 服务脚本以单独的非 root 用户身份在启动时启动带有多个容器的 podman pod，podman 甚至有一个命令来创建这些脚本……所以，这绝对是可以修复的。您可能应该问一个新问题！可能您只是错过了一些比弄清楚非登录进程是否以及在哪里可以找到 dbus 用户会话总线（如果启动的话）更容易修复的东西。
默认情况下，您将获得以 root 用户身份运行的 shell。一旦您拥有 root 权限，您就可以使用其他工具以 ABC 用户身份启动交互式会话。例如，如果已为 ABC 用户分配了普通交互式 shell 并具有普通主目录：
将为您提供一个会话（shell），就像您刚刚以 ABC 用户身份登录一样。现在您输入的命令将具有 ABC 用户的权限。输入“exit”将返回以 root 用户身份运行的 shell，另一个
exit命令将返回以您的帐户运行的 shell。命令是否应该
podman对调用它们的用户敏感？理论上不需要，但应用程序通常配置为在某个特定的 Linux 用户下运行。尝试以其他用户身份启动/停止/管理应用程序会遇到问题。但是，通常会留下文档，说明如何在服务器上登录您自己的（不同）帐户，然后在运行应用程序命令之前切换到应用程序的帐户。