简介：在配置远程开发环境的免密登录时，常遇到 systemd 用户会话无法连接、Gateway 服务检查失败等问题。本文从原理出发，拆解 systemctl --user 报错 “No medium found” 的根因，并给出 loginctl enable-linger 与 XDG_RUNTIME_DIR 的修复方案，帮助开发者快速恢复无密码 SSH 会话下的后台服务能力。
在远程开发与云端编译场景中，免密登录已经成为提高效率的标准配置。通过密钥认证，开发者可以避免每次连接都输入密码，从而让自动化脚本、持续集成流水线以及远程编辑器能够顺畅地建立会话。然而，免密登录并非总是“开箱即用”。不少开发者在配置完成后，执行某些需要用户级后台服务支持的命令时，会突然遇到类似如下的报错：
Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to bus: No medium found
这个错误表面上看起来像是 systemd 服务没有运行，但深入排查后会发现，它与当前 SSH 会话是否被系统正确识别为“用户会话”密切相关。本文将围绕这一报错，从 systemd 用户会话机制、SSH 免密登录的会话差异、以及 loginctl linger 配置等角度，系统性地解释问题成因，并给出可复用的修复方案。
该问题最典型的触发场景是：用户通过免密登录方式接入一台远程开发主机，随后尝试启动或检查某个依赖用户级 systemd 服务的组件。这个组件可能是开发环境中的网关服务、后台守护进程，也可能是某些自动启动的任务管理器。它们在启动前会先检查 systemctl --user 是否可用，如果检测失败，就会抛出“Gateway service check failed”这样的错误。
报错中的关键信息是：
systemctl --user unavailable: Failed to connect to bus: No medium found
这里的 “No medium found” 并不是指磁盘介质不存在，而是 systemd 在尝试连接用户总线时，找不到对应的通信端点。通俗地说，就是当前进程无法访问属于该用户的 D-Bus 会话总线，而 systemctl --user 需要借助这个总线与用户级 systemd 实例通信。
为了更清楚地理解这一点，需要先了解 systemd 用户会话的基本原理。
在 Linux 系统中，systemd 不仅管理系统级服务，还可以为每个登录用户启动一个用户级 systemd 实例。这个用户级实例负责管理该用户自己的后台服务，比如桌面环境组件、开发工具守护进程等。用户级 systemd 实例与系统级实例相互独立，互不干扰。
systemctl --user 命令用于管理用户级服务。它的工作方式是连接到一个用户级的 D-Bus 总线，而这个总线通常由 systemd 用户实例在用户会话启动时创建。D-Bus 是 Linux 下一种进程间通信机制，它通过“总线”来路由消息。系统总线用于系统级服务，用户会话总线则用于同一用户会话内的进程通信。
当用户通过图形界面登录或者通过 SSH 建立交互式会话时，系统通常会为该会话分配一个用户级 systemd 实例，并创建对应的 D-Bus 通信端点。但如果用户是通过免密登录方式，特别是某些自动化工具发起的非交互式 SSH 连接，就可能出现没有启动用户级 systemd 实例、或者没有正确设置会话环境变量的情况。
此时执行 systemctl --user，命令会尝试连接用户 D-Bus 总线，但由于通信端点不存在或者路径无效，就会返回 “Failed to connect to bus: No medium found” 这样的报错。
这里有必要澄清一个常见误区：免密登录本身并不是导致 systemd 用户会话失败的根本原因，但它确实会显著提高触发概率。原因在于，免密登录经常与以下三种使用方式同时出现：
非交互式 SSH 会话：自动化脚本、远程部署工具、远程编辑器插件等通常使用免密登录来建立 SSH 连接。这类连接可能不会完整初始化用户登录环境，导致用户级 systemd 实例没有被正确启动。
会话类型差异：SSH 连接可以是交互式 shell 登录，也可以是非登录、非交互式命令执行。后者不会像常规登录那样完整触发 PAM 会话流程，从而影响用户级 systemd 实例的创建。
环境变量缺失：systemctl --user 需要知道用户 D-Bus 总线的地址，这个地址通常通过 XDG_RUNTIME_DIR 和 DBUS_SESSION_BUS_ADDRESS 等环境变量传递。如果 SSH 会话没有正确设置这些变量，命令就无法找到通信端点。
综合来看，免密登录更容易暴露用户在会话管理与环境配置上的疏漏，因此也更容易遇到该错误。
在应用修复方案之前，建议先进行几项基础检查，以确认问题范围：
确认用户级 systemd 实例是否运行
可以尝试以下命令：
systemctl --user status
如果返回错误，说明当前环境确实无法连接用户级 systemd 实例。
检查当前环境变量
执行：
echo $XDG_RUNTIME_DIRecho $DBUS_SESSION_BUS_ADDRESS
如果输出为空或路径无效，说明会话环境变量缺失或错误。
检查用户 linger 状态
执行：
loginctl show-user $(whoami) | grep Linger
如果显示 Linger=no，说明该用户在登出后用户级服务不会被保留。对于需要长期运行后台服务的远程开发场景，这通常是需要开启的。
针对上述问题，最直接有效的修复方式是在执行相关命令之前，完成以下两步配置：
loginctl enable-linger $(whoami)export XDG_RUNTIME_DIR=/run/user/$(id -u)
loginctl enable-linger 用于为指定用户开启 lingering 功能。默认情况下，当用户退出最后一个会话时，systemd 会停止该用户的用户级实例，并清理相关运行时状态。这对于需要长时间保持后台服务运行的场景并不友好。
开启 lingering 后，即使用户完全登出，systemd 也会继续保留该用户的用户级实例。这意味着用户级服务可以在用户不活跃登录时继续运行，比如定时任务、代理服务、数据库守护进程等。对于远程开发主机尤其是云端编译节点而言，这是一个非常实用的配置。
此外，lingering 还能保证用户级 systemd 实例在系统启动时就被创建，而不必等待用户首次登录。这对于自动化运维来说尤为重要，因为运维脚本可能在任何时刻连接主机并执行需要用户级 systemd 支持的操作。
XDG_RUNTIME_DIR 是 XDG 基础目录规范定义的一个环境变量，用于指向当前用户的运行时目录。该目录通常位于 /run/user/<UID>，用于存放进程运行时所需的临时文件、套接字等。
对于 systemd 用户会话而言，XDG_RUNTIME_DIR 是一个关键路径。用户级 D-Bus 总线套接字通常就存放在该目录下。如果该变量没有正确设置，systemctl --user 就无法定位 D-Bus 通信端点，从而出现连接失败。
在交互式登录中，systemd 和登录管理器通常会自动设置该变量。但在某些非交互式 SSH 会话或自动化连接中，该变量可能缺失。手动导出：
export XDG_RUNTIME_DIR=/run/user/$(id -u)
可以确保命令使用正确的运行时目录。
仅开启 lingering 而不设置 XDG_RUNTIME_DIR，用户级 systemd 实例可能已经在后台运行，但当前进程依然不知道去哪里找 D-Bus 套接字。仅设置 XDG_RUNTIME_DIR 而不开启 lingering，则可能因为用户级实例尚未启动而无法连接。因此，两者需要配合使用，才能在当前会话和后续会话中稳定解决问题。
对于临时调试，可以直接在执行命令前运行上述两条指令。但如果希望一次配置、长期受益，建议采用持久化方案。
linger 状态只需要开启一次，系统会持久保存。执行：
sudo loginctl enable-linger $(whoami)
之后可以通过以下命令验证：
loginctl show-user $(whoami) | grep Linger
输出应为 Linger=yes。
环境变量需要在每个新会话中都生效。可以将以下内容追加到当前用户的 shell 配置文件中，例如 ~/.bashrc 或 ~/.profile：
export XDG_RUNTIME_DIR=/run/user/$(id -u)
这样，无论是交互式登录还是后续的非交互式命令执行，只要 shell 会读取配置文件，环境变量就能正确设置。
完成上述配置后，重新建立 SSH 连接，然后执行：
systemctl --user status
如果能够正常显示用户级 systemd 实例状态，说明修复成功。此时再次运行之前报错的网关服务检查命令，应该不再出现 “No medium found” 错误。
如果上述方案无法立即解决问题，还可以考虑以下备选思路：
显式指定 D-Bus 会话总线地址
在某些环境中，即使设置了 XDG_RUNTIME_DIR，DBUS_SESSION_BUS_ADDRESS 仍然可能缺失。可以尝试手动设置：
export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus
不过需要注意，该地址只有在用户级 systemd 实例正常运行且创建了总线套接字之后才有效。
确认用户级 systemd 实例已启动
可以通过以下命令检查用户级 systemd 是否在运行：
ps -u $(whoami) | grep systemd
如果没有任何用户级 systemd 进程，可以尝试手动启动：
systemctl --user start
但前提是当前环境已经满足基本的运行条件。
避免在完全无会话的环境下直接执行用户级服务操作
如果确实需要在无用户会话的自动化场景中执行用户级服务管理，建议先通过开启 lingering 保证用户实例存在，再配合正确的环境变量进行管理。
“Failed to connect to bus: No medium found” 是远程开发中较为常见的 systemd 用户会话错误。它的本质是当前进程无法定位用户级 D-Bus 通信端点，而非服务本身损坏。免密登录由于其非交互性和自动化属性，更容易暴露这类环境配置问题。
通过开启 lingering 和正确设置 XDG_RUNTIME_DIR，可以确保用户级 systemd 实例的稳定运行，并为所有相关命令提供正确的通信路径。对于需要长期运行后台服务的远程开发场景，这两步配置应当成为标准初始化流程的一部分。
理解这类问题的底层机制，不仅有助于快速修复眼前的报错，更能帮助开发者在构建自动化开发环境时，提前规避由用户会话管理引发的各种隐性故障。