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 可能會失敗，或你以為服務建好了，檔案其實不完整。