用 systemctl edit 为 systemd 服务添加 drop-in 覆盖并安全回滚

一、问题场景

调整服务参数时，很多人习惯直接编辑 /usr/lib/systemd/system/xxx.service。在自建机器上这看似可行，但有两个隐患：一是包管理器升级软件包时会用新版单元文件覆盖本地修改，改动会在没有提示的情况下消失；二是厂商默认值和本机策略混在同一个文件里，审计和回滚都很麻烦。

systemd 提供的 drop-in（插入式覆盖）机制正是为这种场景设计的：把差异化配置写进 /etc/systemd/system/<unit>.d/*.conf，加载时与厂商单元文件合并，且优先级更高，软件包升级不会冲突。systemctl edit 是创建和维护 drop-in 的官方入口。

二、原理与目录约定

单元文件搜索路径的优先级大致为：/etc/systemd/system > /run/systemd/system > /usr/lib/systemd/system（部分发行版为 /lib/systemd/system）。drop-in 目录与主单元同名加 .d 后缀，例如 myapp.service 对应 myapp.service.d/。

目录内的 .conf 文件按文件名字典序依次合并。不同类别的指令合并规则并不相同：

• 单值指令（如 MemoryMax、Restart）后出现的值覆盖先出现的值；
• 列表类指令（如 Environment、EnvironmentFile）通常为追加；
• ExecStart 这类命令行指令需要先写一行空的 ExecStart= 清空，再重新赋值。

因此不要凭记忆推断合并结果，用 systemctl cat 查看真实合并输出是唯一可靠的做法。

三、最小可运行示例

假设机器上已有一个由 systemd 管理的服务 myapp.service（服务名、路径、端口均为占位值，请按实际环境替换）。

第 0 步：记录现状

systemctl cat myapp.service
systemctl show myapp.service -p Environment -p MemoryMax

先留存原始单元内容和当前属性，便于对比与回滚。

第 1 步：创建 drop-in

sudo SYSTEMD_EDITOR=vim systemctl edit myapp.service

该命令会创建 /etc/systemd/system/myapp.service.d/override.conf 并打开编辑器。写入以下内容：

[Service]
Environment=APP_ENV=staging
Environment=APP_PORT=8080
MemoryMax=512M

注意两点：段头 [Service] 必须存在，否则指令无处归属；环境变量含空格或特殊字符时建议整体加引号。

第 2 步：重新加载并重启

sudo systemctl daemon-reload
sudo systemctl restart myapp.service
sudo systemctl status myapp.service --no-pager

较新的 systemd 在 systemctl edit 保存退出后会自动执行一次 daemon-reload，但显式执行更稳妥，尤其是在脚本或批量操作中。修改单元后如果不重启服务，新环境变量不会进入已运行的进程。

第 3 步：验证合并结果

systemctl cat myapp.service

输出会先显示原始单元文件内容，再以 # /etc/systemd/system/myapp.service.d/override.conf 注释开头显示覆盖片段，这就是合并后的完整视图。

systemctl show myapp.service -p Environment -p MemoryMax

从属性输出中确认环境变量已合并、内存上限已生效。若服务启动失败，可用 journalctl -u myapp.service -n 50 --no-pager 查看原因。

四、回滚

方式一，删除 drop-in 目录后重载，粒度最清晰：

sudo rm -rf /etc/systemd/system/myapp.service.d
sudo systemctl daemon-reload
sudo systemctl restart myapp.service
systemctl cat myapp.service

方式二，执行 systemctl revert myapp.service。该命令会把单元恢复到厂商提供的版本，同时清除本地 drop-in 与掩码状态，适合确认没有其他自定义配置时使用。

回滚后同样用 systemctl cat 与 systemctl show 复核，确认环境变量和 MemoryMax 已消失，避免残留配置继续影响服务。

五、边界与限制

• 该机制只适用于 systemd 管理的单元。容器镜像中通常没有运行 systemd，相关命令无法使用。
• MemoryMax 依赖 cgroup 内存控制器，需要内核与 systemd 版本支持，且不同发行版默认的 cgroup 版本可能不同；设置后应在 systemctl show 中确认实际值。
• 不同发行版的厂商单元目录可能是 /usr/lib/systemd/system 或 /lib/systemd/system，编写脚本时不要硬编码单一路径。
• systemctl edit --full 会生成完整的 /etc 副本，长期使用会与上游版本持续分叉，除非确需大改，否则优先用 drop-in。
• 单元名称、环境变量值、内存上限都应按实际业务填写，示例中的数值仅用于演示。

六、小结

drop-in 的价值在于把本机策略从厂商文件中分离出来：升级不丢配置，回滚只需删一个目录。实践中记住三条：改完执行 daemon-reload、用 systemctl cat 验证合并、回滚后再次核对属性。养成这套习惯，systemd 服务的定制就会变得可控且可复现。