Linux 修改 systemd unit 后为什么 daemon-reload 仍不够

修改了 /etc/systemd/system/demo-worker.service 或它引用的 EnvironmentFile 后，只执行 systemctl daemon-reload，正在运行的进程仍可能读取旧值。这不是 daemon-reload 失效，而是它负责让 systemd manager 重新认识 unit 文件；已经存在的服务进程不会因为 manager 重读配置就自动重建。

daemon-reload 重新读取了什么

daemon-reload 重载的是 systemd manager 的配置视图：它重新读取 unit 文件并重建依赖关系。它不会等价于服务的 reload，也不会等价于 restart。前者通常是让应用自己重读配置，后者才会结束旧进程并创建新进程。

因此，修改 ExecStart、EnvironmentFile 或 drop-in 后，单独 reload manager 只完成了“准备使用新配置”这一步；旧进程的 PID 和启动环境仍然保持不变。

先定位真正生效的 unit 和环境文件

排查时不要只打开一个猜测中的文件。先看 systemd 最终拼出的内容，再看它从哪里加载：

# 查看主 unit 与 drop-in 的合并结果
sudo systemctl cat demo-worker.service

# 查看实际路径、drop-in 和当前服务环境
sudo systemctl show demo-worker.service \
  -p FragmentPath -p DropInPaths -p Environment -p MainPID

# 查看 EnvironmentFile 所在目录的权限和内容
sudo ls -l /etc/demo-worker/worker.env
sudo sed -n '1,20p' /etc/demo-worker/worker.env

systemctl cat 能发现“改了 /usr/lib，但 /etc/systemd/system 的 drop-in 覆盖了它”这类问题；FragmentPath 和 DropInPaths 则能确认当前实例到底读了哪些文件。模板服务还要把实例名带上，例如 demo-worker@blue.service，否则可能检查错对象。

为什么新 EnvironmentFile 要配合 restart

可以把应用环境理解成服务创建进程时拿到的一份快照。改完环境文件后，按下面的顺序应用：

如果服务支持应用级 reload，systemctl reload 只会调用 unit 中定义的重载动作，是否重新读取环境取决于应用本身。环境变量通常在进程启动时继承，所以想稳定切换环境值，直接使用 restart 更容易判断。

用状态、属性和日志判断结果

“命令没有报错”只能说明 manager 接受了请求，不足以证明应用使用了新值。建议按三层检查：

# 只取最近一次启动后的日志，避免被旧输出误导
sudo journalctl -u demo-worker.service -n 30 --no-pager

# 需要观察后续启动时再跟随日志
sudo journalctl -u demo-worker.service -f

不要把环境文件里的敏感值直接打印到共享日志。更稳妥的做法是让程序记录非敏感的配置版本、目标环境名或脱敏后的校验结果。

常见问题

只改 EnvironmentFile，需要 daemon-reload 吗？

如果 unit 文件没有变化，严格说 manager 不一定需要重新读取 unit；但统一执行“daemon-reload 后 restart”能覆盖 unit、drop-in 和环境文件同时变更的部署场景，减少遗漏。

为什么 restart 后还是旧值？

优先检查 systemctl cat 展开的路径、drop-in 的覆盖顺序、EnvironmentFile 的权限与格式，以及是否重启了正确的模板实例。

reload 和 restart 可以互换吗？

不能。reload 依赖服务实现的重载动作，restart 会创建新进程；涉及启动环境时，restart 的语义更明确。

什么时候需要 reset-failed？

只有服务此前处于 failed 且需要清理失败状态时才考虑它；它不会替代 daemon-reload，也不会把旧环境变成新环境。