标题

随着自动化助手类应用在开发、测试与个人任务管理中的使用频率不断提高，越来越多开发者开始尝试在本地主机、虚拟机或云主机中快速部署类似“养虾”玩法的智能代理服务。部署过程看似简单，但在启用免密登录、希望以非交互方式拉起服务时，常常会遇到一些与用户会话、系统服务管理相关的环境问题，导致服务无法正常启动。

本文将围绕这一典型场景展开，重点分析免密登录环境下执行服务健康检查时可能出现的报错，并给出清晰、可复用的排查与修复方案。内容会覆盖问题现象、根因分析、必要的前置配置以及验证步骤，帮助读者在少走弯路的前提下完成部署。

一、问题背景：为什么免密登录会影响服务启动

在开发或运维场景中，为了提升自动化效率，通常会为远程主机配置免密登录。这样脚本、CI 流程或部署工具便可以在不手动输入密码的情况下执行指令。然而，免密登录建立的会话与常规交互式登录存在明显差异，其中最关键的区别在于它不一定具备完整的用户会话环境。

许多现代服务管理工具在启动用户级服务时，依赖于用户会话总线（user bus）和用户级服务管理器。若免密登录会话没有正确初始化这些组件，就会导致服务检查失败，典型表现如下：

Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to bus: No medium found

这一错误并不表示应用自身存在缺陷，而是说明当前会话无法连接用户级 systemd 总线，服务管理器无法对用户服务进行状态查询与启停操作。

二、错误拆解：每个关键词代表什么

为了更准确地理解问题，建议将报错拆成三部分进行分析。

1. systemctl --user unavailable

systemctl --user 用于管理当前用户级别服务，而不是系统级服务。系统级服务由 root 或特权用户通过 systemctl 管理，用户级服务则存储在用户目录下，只影响当前用户会话。若用户级 systemd 实例尚未启动，systemctl --user 就会不可用。

2. Failed to connect to bus

用户级 systemd 通过 D-Bus 用户会话总线进行通信。D-Bus 是进程间通信机制，用户会话总线负责连接同一用户下的多个进程。免密登录如果没有正确设置 XDG_RUNTIME_DIR，则客户端不知道应该连接哪一个用户总线，自然无法通信。

3. No medium found

该提示通常表示无法找到有效的通信端点或运行时目录。也就是说，当前会话既没有关联到 /run/user/<UID> 下的运行时目录，也没有可用的总线地址，导致连接失败。

三、修复前的必要理解：linger 与运行时目录

解决该问题的核心，是让用户即使在没有完整交互登录的情况下，也能拥有持续运行的用户服务环境。这里涉及两个概念：linger 机制和 XDG_RUNTIME_DIR。

1. 启用 linger

loginctl enable-linger <用户名> 的作用是允许指定用户在系统启动后，即可拥有用户级服务管理环境，而无需等待该用户登录。对于自动化部署、远程执行和后台服务运行来说，这是一项非常重要的配置。

启动 linger 后，系统会在引导阶段为该用户创建用户管理器，同时生成对应的运行时目录。这样即使用户后续通过免密方式连接，也能复用已经存在的用户会话环境。

执行方式如下：

loginctl enable-linger $(whoami)

这里使用 $(whoami) 自动代入当前用户名，避免手动输入错误。执行后建议确认状态：

loginctl show-user $(whoami) | grep Linger

输出若包含 Linger=yes，则表示配置已生效。

2. 确认运行时目录

XDG_RUNTIME_DIR 是用户运行时文件的存放目录，通常位于：

/run/user/<UID>

该目录权限应仅允许当前用户访问。免密登录时，部分 shell 不会自动设置该变量，导致后续工具无法定位用户总线。可手动导出：

export XDG_RUNTIME_DIR=/run/user/$(id -u)

其中 $(id -u) 会返回当前用户数字 ID。该目录是否存在也值得检查：

ls -ld /run/user/$(id -u)

如果目录不存在，通常说明用户会话尚未正确初始化，可再次确认 linger 是否已启用。

四、完整修复步骤

综合上述分析，建议按以下顺序执行修复。

步骤一：启用用户 linger

loginctl enable-linger $(whoami)

该命令只需执行一次，配置会持久保留。

步骤二：导出运行时目录变量

export XDG_RUNTIME_DIR=/run/user/$(id -u)

如果是在脚本中使用，建议将其写入脚本顶部，确保后续命令共享环境。

步骤三：验证用户级 systemd 是否可用

systemctl --user status

若命令返回服务状态列表，说明用户级 systemd 已正常连接。若仍提示无法连接总线，可进一步检查：

echo $XDG_RUNTIME_DIR
ls -ld $XDG_RUNTIME_DIR

确认变量存在且目录有效。

步骤四：重新执行服务检查或启动命令

在完成上述配置后，再执行原来的服务健康检查或启动指令，通常可正常通过。若应用仍报告检查失败，建议排查服务本身的用户级 unit 文件是否正确加载。

五、脚本化处理建议

对于需要频繁部署的场景，可以将上述配置封装为一个初始化脚本，例如：

#!/usr/bin/env bash
set -e
# 启用用户 linger，确保后台服务可持续运行
loginctl enable-linger "$(whoami)"
# 设置用户运行时目录
export XDG_RUNTIME_DIR="/run/user/$(id -u)"
# 校验运行时目录
if [ ! -d "$XDG_RUNTIME_DIR" ]; then
    echo "运行时目录不存在，请确认 linger 配置是否生效。"
    exit 1
fi
# 验证用户级 systemd
systemctl --user status >/dev/null 2>&1
if [ $? -ne 0 ]; then
    echo "用户级 systemd 仍不可用，请检查 D-Bus 会话配置。"
    exit 1
fi
echo "环境准备完成，可以继续执行服务部署。"

将上述脚本纳入部署流程，可有效避免因为会话环境缺失导致的重复排查。

六、常见误区与注意事项

在实际操作中，还会遇到一些容易忽略的问题。

1. 误用 sudo 执行用户级命令

systemctl --user 必须在目标用户身份下执行。若通过 sudo 切换用户，但没有继承正确的用户环境，仍可能失败。建议直接以目标用户登录后执行，或使用 machinectl shell 等能初始化完整会话的方式。

2. 只导出变量但未启用 linger

仅设置 XDG_RUNTIME_DIR 可以临时解决问题，但如果用户从未登录过或系统刚重启，运行时目录可能尚未创建。linger 的作用正是为了保证目录和用户管理器的持续可用。

3. 忽略 shell 类型差异

不同 shell 对环境变量的加载规则不同。对于非交互式脚本，必须显式导出 XDG_RUNTIME_DIR，不能依赖默认配置文件自动加载。

七、总结

免密登录下的用户级服务启动失败，多数不是应用问题，而是用户会话环境未完整建立。通过启用 linger 和正确设置运行时目录，可以快速恢复用户级 systemd 总线连接，使服务检查与启停操作正常运行。

对于开发者而言，理解这一机制不仅有助于解决当前部署问题，也能更深入地掌握 Linux 用户会话、systemd 用户实例与 D-Bus 之间的关系。后续无论是搭建自动化助手、部署脚本型代理，还是在云主机中运行常驻用户服务，都能更从容地应对类似环境配置挑战。