systemd-delta 怎样找出被覆盖的 unit 配置

当一个服务的行为和发行版默认值不一致时，先不要猜参数，也不要直接编辑 /usr/lib/systemd/system。systemd-delta 专门用来找出高优先级目录覆盖低优先级目录的配置文件，并能把 unit 的 drop-in 变化单独列出来。

官方文档：https://www.freedesktop.org/software/systemd/man/latest/systemd-delta.html

最实用的排查路径是：先全局扫描，再限定到 systemd/system 或 /run，接着用 --type 和 --diff 缩小差异，最后用 systemctl cat 与 systemctl show 对照实际 unit。

先理解 unit 为什么会被覆盖

systemd 会在多个配置目录中寻找同名文件。通常可以把优先级理解为：/etc/ 最高，/run/ 次之，/usr/lib/ 较低。高优先级目录里的同名文件会覆盖低优先级文件；而 服务名.service.d/ 目录里的 drop-in 则是在主 unit 旁边追加或覆盖片段。

因此，服务包升级后“默认值变了”、管理员手工加过参数、或者临时运行时配置残留，都可能让最终结果不再等于 /usr/lib/systemd/system/ 里的原文件。systemd-delta 解决的是“哪些文件改变了层级关系”，不是直接替你判断业务上哪一个参数正确。

从全局扫描收窄到 systemd/system

不确定改动来自哪里时，先执行最宽的扫描：

# 查看所有配置目录中被覆盖、重定向或扩展的配置
systemd-delta --no-pager

# 只关注系统 unit 的配置树，减少 tmpfiles.d 等其它目录的噪声
systemd-delta --no-pager systemd/system

# 只看运行时目录，适合排查临时生成或启动后注入的配置
systemd-delta --no-pager /run

命令参数既可以是目录前缀，也可以是配置子目录。systemd/system 表示跨各个配置根目录比较系统 unit；/run 则把范围限制到运行时配置。先宽后窄的好处是不会把一个来自 tmpfiles.d 的差异误认为服务 unit 改动。

输出中的 overridden 表示高优先级文件覆盖了低优先级文件且内容发生变化；equivalent 表示虽然发生覆盖，但内容相同；redirected 表示文件指向了另一处；drop-in 相关的 extended 则用于显示 unit 目录中的扩展配置。

用类型过滤和 diff 看清变化

全量结果较多时，先按差异类型过滤，再决定是否展开 diff：

# 只列出内容确实不同的被覆盖文件
systemd-delta --no-pager --type=overridden

# 只列出 unit 的 drop-in 扩展，便于定位 Override.conf 类文件
systemd-delta --no-pager --type=extended systemd/system

# 对修改过的覆盖文件显示差异；--diff 默认会展开差异
systemd-delta --no-pager --type=overridden --diff=true systemd/system

# 需要脚本处理时关闭分页，避免 less 接管标准输出
systemd-delta --no-pager --type=overridden --diff=false systemd/system

--type 的值可以用逗号组合，例如 overridden,extended。如果只想知道“有没有本地改动”，用 overridden；如果服务看起来没改主文件，却始终多出某个环境变量、资源限制或依赖关系，优先查看 extended。

用 systemctl cat 回到实际 unit 内容

systemd-delta 负责发现“哪里不同”，确认某个服务最终看到了什么，还要回到 unit 本身：

# 展示主 unit 及其 drop-in，并标出每段内容的来源文件
systemctl cat example.service

# 查看 systemd 当前解析出的关键属性，而不是只看磁盘上的某个文件
systemctl show example.service \
  --property=FragmentPath,DropInPaths,ExecStart,Environment

# 修改 unit 或 drop-in 后，通知管理器重新读取配置
systemctl daemon-reload

FragmentPath 可以帮助确认主 unit 来自哪一层，DropInPaths 能指出正在参与合并的片段路径。两者结合 systemd-delta 的差异分类，通常足够回答“是谁覆盖了它”和“当前生效来源在哪里”。

修复时优先删除或修改明确属于本机的 /etc 覆盖，不要直接改包管理器管理的 /usr/lib 文件。修改后先执行 daemon-reload，再按服务自身的变更风险决定是否重启。

常见问题

为什么 systemd-delta 没有显示服务名？

它默认展示的是配置文件差异，未必按服务状态排序。用 systemd-delta systemd/system 收窄范围，再用 systemctl cat 服务名.service 查看具体 unit。

equivalent 是否说明可以忽略？

它表示覆盖文件内容相同，但仍说明本机存在更高优先级副本。排查“来源不明”时不要只看内容，也要记录这份副本为什么存在。

drop-in 和主 unit 覆盖怎么区分？

先看 --type=overridden，再看 --type=extended。前者偏向同名主文件被替换，后者偏向 服务名.service.d/ 目录中的扩展片段。

总结：systemd-delta 用来发现配置层级差异，--type 用来分类，--diff 用来阅读变化，systemctl cat/show 用来确认实际 unit 来源。按这条链路排查，通常不需要在多个目录之间盲目搜索。