systemctl --user 出现 Failed to connect to bus: No medium found 怎么办

在 Linux 主机上用 sudo -iu 项目用户 切过去，再运行 systemctl --user daemon-reload，结果出现 Failed to connect to bus: No medium found。我在 2026 年 10 月把 Claude Code Remote Control 做成常驻服务时就遇到过这个 systemctl –user No medium found 错误。

先说结论：这通常不是 systemd 坏了，也不是 unit 文件写错了，而是 sudo -iu 开的 shell 没有该用户的 user bus。 修复方法是回到有 sudo 权限的管理员账号，开启 linger、确认 user manager 在运行，再用 sudo -u 明确带上 XDG_RUNTIME_DIR 和 DBUS_SESSION_BUS_ADDRESS 运行 systemctl --user。不要用 sudo systemctl --user。

本文是我 2026 年 10 月在 Oracle Cloud 的 Ubuntu 24.04（ARM64）主机上部署时的记录与整理，命令以 Ubuntu 24.04 为例，用户名都换成了 project-a 这类示例。其他发行版或 systemd 版本的行为可能不同，以官方文档为准。

错误长什么样、什么时候出现

我当时的操作很简单：用管理员账号（Ubuntu 默认的 ubuntu）SSH 进主机，切到项目用户，在那里管理它自己的 systemd user service。

sudo -iu project-a
systemctl --user daemon-reload
# Failed to connect to bus: No medium found

这个项目用户没有密码，平时不会直接登录，只靠 sudo -iu 切过去。整套 Remote Control 常驻架构见《Oracle Cloud 运行 Claude Code Remote Control 常驻教程》，这篇只处理这个错误。

systemctl –user No medium found 的原因

systemctl --user 要连到“这个用户自己的 systemd user manager”，连接是通过 user D-Bus。一般 SSH 登录时，登录流程会替你准备好 /run/user/<UID>/ 这个运行目录，并设置 XDG_RUNTIME_DIR 等环境变量。

sudo -iu 开的 shell 不是完整的登录会话，可能没有这些变量，user bus 也可能还没建立。systemctl 找不到要连的 bus，就会报 No medium found。

可以先在那个 shell 里确认：

echo "$XDG_RUNTIME_DIR"
echo "$DBUS_SESSION_BUS_ADDRESS"
ls -l "/run/user/$(id -u)/bus"

如果前两行是空的，或者 bus 文件不存在，就是这种情况。

修复方法：从管理员账号指定 user bus

以下命令都在有 sudo 权限的管理员账号运行，不是在 sudo -iu 的 shell 里。

先开启 linger，确认 user manager 在运行

PROJECT_USER=project-a
uid=$(id -u "$PROJECT_USER")

sudo loginctl enable-linger "$PROJECT_USER"
loginctl show-user "$PROJECT_USER" -p Linger   # 预期 Linger=yes

# 如果 /run/user/$uid/bus 不存在，先看 user manager 的状态
systemctl status "user@${uid}.service" --no-pager

linger 让这个用户的 user manager 在开机时就启动，退出登录后也保留（loginctl 官方说明，2026 年 10 月 12 日查阅）。要让服务在 SSH 断开后继续运行、重启后自动恢复，这一步本来就少不了。

用 XDG_RUNTIME_DIR 和 DBUS_SESSION_BUS_ADDRESS 运行

sudo -u "$PROJECT_USER" \
  XDG_RUNTIME_DIR="/run/user/$uid" \
  DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$uid/bus" \
  systemctl --user daemon-reload

每次都敲这么长很容易出错，可以在管理员的 shell 里包成一个函数：

uctl() {
  sudo -u "$PROJECT_USER" \
    XDG_RUNTIME_DIR="/run/user/$uid" \
    DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$uid/bus" \
    systemctl --user "$@"
}

uctl daemon-reload
uctl enable --now claude-project-a.service
uctl status claude-project-a.service --no-pager -l

看日志也是同样的方式：

sudo -u "$PROJECT_USER" \
  XDG_RUNTIME_DIR="/run/user/$uid" \
  DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$uid/bus" \
  journalctl --user -u claude-project-a.service -n 80 --no-pager

为什么不能用 sudo systemctl –user

sudo systemctl --user ... 看起来像“用 sudo 权限操作 user service”，但 sudo 默认可能切换成 root，操作的是 root 的 user manager，不是 project-a 的。结果可能是 reload 错了对象、找不到服务，或者看到不相干的状态。

要操作某个用户的 user service，就要以那个用户的身份（sudo -u project-a）运行，并指向那个用户的 bus。

enabled、active (running)、inactive (dead) 有什么区别

bus 连上之后，下一个常见误会是看到 enabled 就以为服务在运行。我当时就遇到过：一个 Remote Control 服务显示 Loaded: ... enabled，但 Active: inactive (dead) (Result: exit-code)；同一时间另一个服务是 active (running)，Linger=yes 也确认过了。

检查是否 enabled 和当前状态：

uctl is-enabled claude-project-a.service
uctl status claude-project-a.service --no-pager -l
uctl --failed --no-pager

只有确定服务是被刻意停止、没有未解决的启动错误时，才直接 start。如果看到 status=1/FAILURE，先读 journal。我那次看到的 exit code 1，目前没有足够的日志能确认根因，所以这里不写成“找到原因”。服务一直起不来时的排查顺序，见《一台主机运行多个 Claude Code Remote Control》。

unit 文件没写完整：用 systemd-analyze 检查

另一个我实际遇到的情况：用 shell 的 heredoc（cat > 文件 <<'EOF' ... EOF）写 unit 文件，结束标记没有正确收尾，文件少了最后的 [Install] 段落。结果可能是 systemctl enable 失败，或者你以为服务建好了，文件其实不完整。

写完 unit 先检查，再 reload：

tail -n 12 ~/.config/systemd/user/claude-project-a.service
systemd-analyze --user verify ~/.config/systemd/user/claude-project-a.service

一个完整的 user service 结尾应该有：

[Install]
WantedBy=default.target

没有 [Install] 段落，enable 就不知道要把服务挂在哪个 target 下。如果 systemd-analyze --user 也因为 user bus 无法运行，就由管理员检查文件内容，再用前面的方式 daemon-reload。修文件时只动出问题的那一个，不要顺手覆盖其他正常运行的 service。

修好之后怎么验收

1. loginctl show-user project-a -p Linger 是 Linger=yes。
2. uctl is-enabled 是 enabled，uctl status 是 active (running)。
3. 日志里能看到进程正常启动的消息（以 Claude Code Remote Control 来说是 Connected 和环境名称）。
4. 完全关掉 SSH，重新连回来，服务还在运行。
5. 找一个没有重要工作在运行的时段重启主机，确认服务自动恢复。

active (running) 只能证明进程存在，Remote Control 有没有真的连上，要看日志和手机或网页上的环境列表。完整的常驻设置在《Oracle Cloud 运行 Claude Code Remote Control 常驻教程》；整个网站用了哪些工具，见《Jason Finance 从零到一》。

常见问题

systemctl --user 为什么会出现 No medium found？

常见情况是用 sudo -iu 切换到另一个用户后运行。这种 shell 不是完整登录，可能没有设置 XDG_RUNTIME_DIR 和 user D-Bus 地址，systemctl 找不到该用户的 user manager。这不代表 systemd 坏了，也不代表 unit 文件写错了。

怎么修复 systemctl --user No medium found？

回到有 sudo 权限的管理员账号，先用 loginctl enable-linger 开启该用户的 linger、确认 user@UID.service 在运行，再用 sudo -u 加上 XDG_RUNTIME_DIR=/run/user/UID 和 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/UID/bus 运行 systemctl --user。

可以直接用 sudo systemctl --user 吗？

不建议。sudo 默认可能切换成 root，操作的是 root 的 user manager，不是项目用户的，结果会改错地方或看错状态。

service 显示 enabled，为什么没有在运行？

enabled 只表示满足启动条件时 systemd 会尝试启动，active (running) 才代表进程现在存在。服务被手动停止或启动失败后，可能仍是 enabled，但状态是 inactive (dead)。

activating (auto-restart) 是什么意思？

systemd 正在按 Restart 设置重新启动这个服务，通常代表它一直启动失败。这时应该先看 journalctl 的日志，而不是一直手动 restart。

怎么检查 unit 文件有没有写完整？

用 tail 看文件结尾，再用 systemd-analyze --user verify 检查。如果缺少 [Install] 段落，systemctl enable 可能会失败，或者你以为服务建好了，文件其实不完整。