服务配置变更前必须执行 systemctl daemon-reload，否则新配置不生效；EnvironmentFile 路径错误会导致静默失败；Restart=on-failure 不覆盖卡死、子进程崩溃等场景；回滚需同步清理 /run/systemd/generator 下生成文件。
服务配置变更前必须验证 systemctl daemon-reload 是否生效
很多运维人员改完 /etc/systemd/system/*.service 文件后直接 systemctl restart xxx，结果服务启动失败或行为异常——根本原因是 systemd 并未加载新配置。daemon-reload 不是可选步骤，而是强制前置动作。它会重新解析所有 unit 文件，重置依赖关系和环境变量，跳过这步等于在旧配置上强行重启。
实操建议：
- 每次修改 service 文件后，先执行
systemctl daemon-reload，再用systemctl cat xxx.service确认内容已更新 - 检查是否报错：若输出含
Failed to reload settings: Invalid argument，说明语法错误（如多了一个等号、路径含空格未引号包裹） - 对线上服务，建议搭配
systemctl show --property=ExecStart,Environment,Restart xxx.service对比变更前后关键字段
EnvironmentFile 路径错误会导致 systemctl start 静默失败
使用 EnvironmentFile 加载外部变量时，路径写错不会立即报错，但服务启动时可能因变量为空导致进程崩溃，日志里只显示 main process exited, code=exited, status=1/FAILURE，排查成本极高。
常见陷阱：
-
EnvironmentFile默认不支持通配符，/etc/default/myapp.conf写成/etc/default/myapp*会被忽略 - 路径未加前缀
-时（如EnvironmentFile=/missing/file.env），文件不存在直接终止启动；加了-（EnvironmentFile=-/missing/file.env）才忽略缺失 - 文件内变量不能含空格赋值，
API_URL = https://api.example.com是非法的，必须写成API_URL=https://api.example.com
Restart=on-failure 不等价于 “服务挂了就自动拉起”
这个参数常被误认为万能兜底，实际它只在进程非零退出、被信号终止（如 SIGKILL 以外）、超时启动失败时触发重启。而以下情况它完全不响应：
- 进程卡死但未退出（CPU 占满、死锁、无限循环）
- 子进程崩溃但主进程仍在运行（典型如 Node.js 的 cluster 模式）
- 磁盘写满、OOM killer 杀掉进程（此时 exit code 是 137，
on-failure默认不覆盖）
更稳妥的做法是组合使用：
Restart=on-failure RestartSec=5 StartLimitIntervalSec=60 StartLimitBurst=3
并配合外部健康检查（如 curl -f http://localhost:8080/health）做补位。
配置回滚必须同步清理 /run/systemd/generator 下的动态单元
某些配置项（如 RuntimeDirectory、StateDirectory）会在服务首次启动时由 systemd 自动生成临时 unit 文件到 /run/systemd/generator/。如果仅回退 service 文件但没清空这些生成文件，下次 daemon-reload 可能沿用旧逻辑，导致行为不一致。
安全回滚步骤：
- 停止服务：
systemctl stop xxx.service - 还原 service 文件和 EnvironmentFile
- 手动删除对应生成文件：
rm -f /run/systemd/generator/xxx.service.d/ - 执行
systemctl daemon-reload，再启动
注意：/run 是内存文件系统，重启后自动清空，但热变更场景下这个细节极易被忽略。
