cat 查看单元定义
systemctl cat 输出一个单元的完整合成定义：主单元文件加上所有 drop-in 片段（.d 目录下的 .conf），按生效顺序合并后展示，每个片段前用 # 注释标出来源路径。当出现「改了配置没生效」「不知道到底是哪个文件在起作用」时，它是唯一可靠的权威视图，比逐个目录翻文件快得多。
基本信息
| 适用平台 | Linux（systemd） |
|---|---|
| 命令语法 | systemctl cat 单元... |
| 输出内容 | 主单元文件与全部 drop-in，按生效顺序拼接，来源路径以注释形式给出 |
| 相关命令 | systemctl show -p FragmentPath 与 -p DropInPaths 看真实加载路径；systemctl edit 创建 drop-in |
| 权限说明 | 读取单元文件普通用户即可，修改需要 root |
典型使用场景
- 确认最终配置：单元文件与 drop-in 叠加之后到底长什么样
- 排查改了不生效：先确认生效源是不是你以为的那个文件
- 审计第三方发行包：看服务实际带有哪些安全与资源限制
- 排容器与编排问题：确认 ExecStart 与 Environment 的真实取值
- 交付留痕：把 cat 的输出附进变更单，作为配置基线
常用示例
常用示例
systemctl cat nginx # 完整合成定义
systemctl cat myapp | sed -n '/\[Service\]/,$p' # 只看 Service 段
systemctl show myapp -p FragmentPath # 主单元文件的实际路径
systemctl show myapp -p DropInPaths # 生效的 drop-in 列表
ls /etc/systemd/system/myapp.service.d/ # 手工查看 drop-in 目录
systemctl cat docker.service containerd.service # 一次查看多个单元相关查看方式对比
| 命令 | 看到的内容 | 注意 |
|---|---|---|
| systemctl cat | 磁盘上合成后的全文与来源路径 | 不反映内存中尚未 reload 的旧定义 |
| systemctl show -p FragmentPath | 实际加载的主单元文件路径 | 用于确认 /etc 是否覆盖了 /usr/lib 的版本 |
| systemctl show -p DropInPaths | 实际生效的 drop-in 列表 | 输出为空说明没有 drop-in |
| systemctl status | 运行状态与最近日志 | 不给完整配置，只能辅助判断 |
| systemctl --version | systemd 版本 | 部分指令与配置字段依赖版本 |
输出里每个 # 注释行标出该片段来自哪个文件；drop-in 按文件名字典序依次应用、后面的覆盖前面的，所以 20- 开头的片段会盖过 10- 开头的。排查「改了没生效」的第一步就是看这些来源注释。
cat 读的是磁盘当前内容，而运行中的管理器用的是上次 daemon-reload 时载入的定义。编辑单元文件后如果 status 提示 unit file changed on disk，说明两者已经不一致，必须 daemon-reload 再重启服务。
想改配置又不想动发行版自带的单元文件，用 systemctl edit 单元 生成 drop-in 片段，它会自动写到 /etc/systemd/system/单元.d/override.conf；systemctl edit --full 则是整份覆盖。前者在软件包升级后仍然保留叠加关系，通常是更稳的做法。