Linux systemctl cat 查看服务 unit 主文件与 drop-in 配置

排查 Linux 服务“配置明明改了却不生效”时，先不要直接重启。systemctl cat 服务名.service 会把主 unit 文件和 drop-in 片段连同文件路径一起打印出来，适合确认配置到底来自哪里；如果磁盘文件刚改过，还要用 systemctl daemon-reload 让 systemd 重新读取，二者不是同一个动作。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemctl.html

systemctl cat 先看哪两类文件

systemd 单元常见有两层来源：主 unit 文件负责完整的基础定义，drop-in 则是放在 服务名.service.d/ 下的局部片段。发行版文件可能位于 /usr/lib/systemd/system 或 /lib/systemd/system，管理员自己的覆盖通常位于 /etc/systemd/system。不要只打开一个目录里的文件就下结论，因为最终排障需要同时知道主文件和覆盖片段。

# 查看 nginx.service 的主文件、drop-in 片段和对应文件路径
systemctl cat nginx.service

如何区分磁盘配置与已加载配置

systemctl cat 主要读取磁盘上的 backing files。若刚修改了 unit 或 drop-in，磁盘内容已经变化，但 systemd manager 可能仍保留旧的加载结果。官方手册特别提醒了这个边界，所以“cat 能看到新文本”不代表当前管理器已经采用它。

# 查看磁盘上的主文件和 drop-in 来源
systemctl cat nginx.service

# 修改配置后只让 systemd 重新读取单元文件
sudo systemctl daemon-reload

# 从管理器属性中确认主文件和 drop-in 路径
systemctl show nginx.service -p FragmentPath -p DropInPaths

可以把检查结果分成三层：FragmentPath 说明主文件在哪里，DropInPaths 说明覆盖片段有哪些，服务当前是否重启则要看 systemctl status 或实际业务状态。重载配置不会自动重新执行 ExecStart，这正是很多“配置改了但进程还是旧行为”问题的分界点。

覆盖配置时的检查清单

需要调整发行版服务时，尽量不要直接编辑 /usr/lib/systemd/system 下的主文件。升级包可能覆盖它，也会让变更来源难以追踪。更稳妥的方式是使用 systemctl edit 创建 drop-in，然后用 systemctl cat 复查合并后的来源。

# 创建或编辑本机覆盖片段，不直接改发行版主文件
sudo systemctl edit nginx.service

# 复查主 unit 与 drop-in 的完整来源
systemctl cat nginx.service

# 让 systemd 重新读取文件；此命令本身不重启服务
sudo systemctl daemon-reload

# 只有确认变更需要进程重新读取时，才单独安排重启
sudo systemctl restart nginx.service

发布前可按“路径、覆盖、加载、进程”四项核对：路径看 FragmentPath 和 DropInPaths；覆盖看 drop-in 是否真的出现；加载看是否执行了 daemon-reload；进程看重启是否符合维护窗口。这样能把文件写错、片段未加载和进程未重启区分开。

相关问题与边界

systemctl cat 会显示最终合并后的单一文件吗？

不会。它会按来源显示主 fragment 和 drop-in 文件，并在输出中标出文件名；排障时应结合各片段的覆盖关系理解结果。

修改 drop-in 后只执行 daemon-reload 就够了吗？

不一定。daemon-reload 让管理器重新读取单元定义，但已运行进程是否需要重启，要看修改的字段和服务行为。

为什么 cat 看到的文本和服务行为不一致？

先确认是否执行过 daemon-reload，再用 show 查看路径和 status 查看当前状态；如果 ExecStart 已改变，通常还要安排一次受控重启。