Linux 服务管理器 EnvironmentFile 变量不生效：文件格式、权限与重载顺序

不少朋友在用 systemd 配置服务时，习惯通过 EnvironmentFile 统一导入环境变量，改完配置后经常遇到新增的变量完全不生效的情况，排查过程很容易卡在几个不起眼的细节上，绝大多数这类问题都和文件格式、权限设置还有重载操作的先后顺序有关。

服务明明重启了，程序却还在使用旧的环境变量，最容易误判的是把问题归咎于 systemd “没有读取文件”。实际排查时，通常要把三个动作拆开：确认 EnvironmentFile 指向了哪个文件，确认 systemd 能否读取它，再确认修改 unit 后是否执行了 daemon-reload 和服务重启。下面用一个最小服务把这条链路跑通。

先做一个能重复验证的最小服务

为了避免应用自身配置覆盖环境变量，先准备一个只输出变量的 unit。下面的路径使用普通测试目录，生产环境可换成专用服务账号可读的位置。

sudo mkdir -p /etc/demo-worker
sudo tee /etc/demo-worker/worker.env >/dev/null /dev/null 

首次加载 unit 后执行：

sudo systemctl daemon-reload
sudo systemctl start demo-worker.service
sudo journalctl -u demo-worker.service -n 20 --no-pager

日志里应出现 APP_MODE=staging APP_PORT=9100。如果这里已经正确，后面的故障模拟就有了可靠基线。

判断 systemd 到底加载了哪一个 EnvironmentFile

先不要凭记忆看文件。用 systemctl cat 看合并后的 unit，再用 systemctl show 查看 systemd 保存的属性：

systemctl cat demo-worker.service
systemctl show demo-worker.service -p FragmentPath -p DropInPaths -p EnvironmentFiles

FragmentPath 应指向 /etc/systemd/system/demo-worker.service，EnvironmentFiles 应显示 /etc/demo-worker/worker.env。如果这里不是预期路径，说明修改的是另一份 unit，或某个 drop-in 覆盖了配置。此时先用：

systemctl show demo-worker.service -p NeedDaemonReload

当结果为 yes 时，systemd 已明确告诉你 unit 文件发生了变化但尚未重新读取。

环境文件格式错在哪里，怎么快速排除

EnvironmentFile 不是任意 shell 脚本。常见写法是每行一个变量：

APP_MODE=staging
APP_PORT=9100
LOG_LEVEL="info"
# 这是注释

下面几类写法要特别小心：

尤其要留意从 Windows 编辑器复制来的文件。可以用：

sudo sed -n 'l' /etc/demo-worker/worker.env
sudo file /etc/demo-worker/worker.env

若每行末尾出现 \r$，先去掉 CRLF 换行，再重启服务。不要直接把环境文件当成可执行脚本运行来判断，它们的解析规则并不相同。

权限检查要看目录链，不只看文件本身

文件显示可读，不代表 systemd 或服务账号一定能走到它。逐级查看目录权限：

sudo ls -l /etc/demo-worker/worker.env
sudo namei -l /etc/demo-worker/worker.env

如果环境文件放在用户目录下，父目录缺少执行权限时，读取仍可能失败。生产配置建议放在 root 管理的专用目录，权限按服务需要收紧；不要为了“先跑起来”把环境文件改成 777。其中包含密码、令牌等敏感值时，还要结合 unit 的运行账号和日志策略，避免通过调试输出泄露。

改动后按正确顺序重载并验证

把 APP_MODE 改成 production，只修改环境文件时可以直接重启：

sudo sed -i 's/^APP_MODE=.*/APP_MODE=production/' /etc/demo-worker/worker.env
sudo systemctl restart demo-worker.service
sudo systemctl status demo-worker.service --no-pager
sudo journalctl -u demo-worker.service -n 10 --no-pager

如果改的是 demo-worker.service 中的 EnvironmentFile= 行，顺序必须变成：

sudo systemctl daemon-reload
sudo systemctl restart demo-worker.service
systemctl show demo-worker.service -p NeedDaemonReload -p EnvironmentFiles
sudo journalctl -u demo-worker.service -n 10 --no-pager

成功状态包括：NeedDaemonReload=no、EnvironmentFiles 指向目标文件，且最新日志输出了新值。oneshot 服务每次重启都会重新执行 ExecStart，正适合验证读取链路；常驻服务则还要确认新进程已经替换旧进程。

三个结果对不上时，按证据定位

排查可以按下面的分支收敛，不需要反复修改配置：

1. systemctl show 路径不对：检查 unit 名称、drop-in 和 systemctl cat 的合并结果。
2. 路径正确但变量没变：确认文件内容，再重启服务；只做 daemon-reload 不会替换已经运行的进程环境。
3. 服务启动失败：先看 journalctl -u demo-worker.service -b，再检查文件存在性、目录链权限和每行格式。
4. systemd 视角已更新但程序仍使用旧值：检查应用是否在启动参数、配置文件或容器环境里覆盖了同名变量。

这套顺序的关键是区分“unit 配置已更新”和“服务进程已更新”。前者由 NeedDaemonReload、EnvironmentFiles 证明，后者要由新一轮启动日志或进程实际环境证明。

相关问题

只修改 EnvironmentFile，必须执行 daemon-reload 吗？

通常不需要。直接重启服务即可重新读取文件；只有修改了 unit 或 drop-in 文件时才需要先执行 daemon-reload。

为什么 daemon-reload 后变量还是旧的？

daemon-reload 只让 systemd 重新读取 unit，不会自动重启业务进程。继续执行 systemctl restart 服务名，再看最新日志。

EnvironmentFile 可以写 export 吗？

不要把它当 shell 脚本使用。优先写成 KEY=value 的简单键值行，并用非敏感测试变量验证解析结果。

怎么确认变量是 systemd 传给程序的？

对短命令服务可看启动日志；常驻服务则结合 systemctl show、服务日志和目标进程的实际环境核对，避免只凭 unit 文件下结论。

把排查动作收成一条命令清单

systemctl cat demo-worker.service
systemctl show demo-worker.service -p NeedDaemonReload -p EnvironmentFiles
sudo namei -l /etc/demo-worker/worker.env
sudo sed -n 'l' /etc/demo-worker/worker.env
sudo systemctl daemon-reload       # 仅当 unit 文件变更
sudo systemctl restart demo-worker.service
sudo journalctl -u demo-worker.service -n 20 --no-pager

先看 systemd 加载的对象，再看文件格式和权限，最后重启并核对新进程输出，通常能把“变量不生效”从模糊感觉变成一个明确的路径、格式或生命周期问题。