我通过用户（即）运行 systemd enable-linger $USER，并通过以下方式与服务交互systemctl --user
我注意到一个奇怪的问题。
采购类型 1
为了让上述 systemd 为用户工作，我需要export XDG_RUNTIME_DIR=/run/user/$(id -u)在我的~/.bashrc
这很好用。
采购类型 2
当我按如下方式获取我的 bashrc 时，systemd 不起作用：
里面.bashrc：
source /path_to_file/my_file.env
里面my_file.env：
XDG_RUNTIME_DIR=/run/user/$(id -u)
当我执行类型 1 和 2 的采购操作时，都会产生相同的结果，echo $XDG_RUNTIME_DIR因此我决定采用类型 2。但是，我注意到当我执行此操作systemctl --user daemon-reload时，守护进程没有运行，并且出现了以下错误：
Failed to connect to bus: No such file or directory
当我恢复到 Souring Type 1 时，错误消失并且一切按预期工作。
我的问题是：我在这里错过了什么？我的主要困惑源于环境变量相同，但最终结果却不同。
答案1
你忘记了export.env 文件中的，所以该变量实际上不是一个环境多变的。
默认情况下，Shell 变量不会导出到环境中。只有对已导出变量的赋值才会自动重新导出；如果XDG_RUNTIME_DIR是全新的变量，它将成为 shell 内部变量，除非您使用export或declare -x内置命令。（或者除非启用了“allexport”shell 选项，但在 .bashrc 中使用它有一些奇怪的陷阱。）
echo $FOO“看到”变量是因为命令行中 $FOO 的扩展是由 shell 解释器本身完成的，而不是由命令完成的 —— 'echo' 根本不必访问环境，而 'systemctl' 则需要。
除了使用 echo 之外，您还可以使用declare -p FOOshell 本身告诉您变量的状态（包括x如果变量被导出则显示标志），或者使用env或printenv从外部进程的角度查看环境是什么样的（非导出的 shell 变量根本不会显示在这里）。
无论如何，你都不应该需要为交互式登录执行此操作。这个特定变量应该在您登录后立即通过 PAM（由 pam_systemd）放入您的环境中 - 甚至在您的 shell 运行之前。
对于需要访问其他用户服务的脚本，systemctl --user -M ${USER}@.host将使 systemctl 本身找到指定用户的运行时目录和 D-Bus 套接字。