Linux 服务管理器 cat-config 怎么确认最终配置：drop-in 合并、来源定位与回滚检查

线上服务重启后还在读旧参数，排查最容易踩的坑就是：你以为你改完配置了，看到的只是某一个配置文件，根本没拿到systemd最终真正生效的那一份。发行版自带的unit文件、管理员放到 /etc/systemd/system 下的覆盖文件，还有运行时生成的drop-in片段，会按优先级一起参与加载，你只单独打开其中一个文件判断，结论肯定不全。

先区分“配置类别”和“服务 unit”

cat-config 这个命令的名字很容易让人误以为它能查看所有systemd配置，其实实际排查的时候要先把两类对象分开处理：systemd-analyze cat-config 更适合查看 system.conf、user.conf 这类由systemd专属配置目录逐层合并出来的全局配置，具体单个服务的unit和对应的drop-in片段，直接用 systemctl cat 展开查看更清晰。

用 cat-config 看清主文件和 drop-in 的合并结果

假设你在机器上调整过systemd管理器的日志级别，别挨个翻文件猜路径，直接让systemd展开它实际读到的完整配置就好：

systemd-analyze cat-config system.conf
systemd-analyze cat-config user.conf

输出结果里一般会自动标注每一段配置对应的实际读取文件名，还会把同名配置文件夹里的片段内容直接接在主配置文件内容后面。这里重点核对三件事：目标配置文件是不是真的在预期路径、你新增的drop-in片段是不是确实被读到了、同一个配置项后面有没有被其他片段重复覆盖。如果只靠find去搜grep找/etc/systemd/system相关内容，大概率会漏掉/usr/lib或者/run里的配置来源。

这里要注意一个边界情况：这个命令输出的合并内容，不等于服务unit最终运行时拿到的属性。比如要排查my-worker.service的环境变量或者文件描述符上限，要继续执行下面的命令组合：

systemctl cat my-worker.service
systemctl show my-worker.service -p Environment -p LimitNOFILE -p FragmentPath -p DropInPaths

FragmentPath 能告诉你主unit文件来自哪个路径，DropInPaths 会把所有覆盖用的drop-in片段完整列出来，show 拿到的属性才是systemd已经解析完的运行时视图。三个步骤对照着看，你才能把“配置文件里写了什么”和“进程最终会拿到什么参数”完全区分开。

从 drop-in 修改到运行状态，按一条可回退路径验收

不要直接改动发行版自带的unit文件，要给服务新增本地自定义覆盖片段的正确操作是：

sudo mkdir -p /etc/systemd/system/my-worker.service.d
sudo editor /etc/systemd/system/my-worker.service.d/override.conf

举个例子，要把单个服务的文件描述符上限调整为65536，操作大概是这样：

[Service]
LimitNOFILE=65536

保存完之后按固定顺序一步步核对就行。daemon-reload 动作只是让systemd重新读取一遍磁盘上的unit文件，完全不会自动重启已经启动的进程，所以重载配置和重启服务是两个完全独立的操作，不能跳过任何一步。

sudo systemctl daemon-reload
systemctl cat my-worker.service
systemctl show my-worker.service -p LimitNOFILE -p DropInPaths
sudo systemctl restart my-worker.service
systemctl is-active my-worker.service
systemctl show my-worker.service -p LimitNOFILE

如果最后输出的属性值还不是你想要的65536，先看DropInPaths 路径是不是指向你刚改的那个预期文件，再检查你写的配置片段里的section是不是不小心写成了[Service]。如果配置属性显示已经正确，但进程实际行为还是没变，就继续检查应用本身是不是自己从其他地方读了另一套资源限制规则，别反复在同一个unit上叠无用的覆盖配置。

systemd-delta 适合做差异盘点，不要把它当最终答案

接手一台没人维护的旧服务器的时候，可以先跑下面的命令，快速找出本机上所有相对厂商默认unit的改动点：

systemd-delta --type=extended
systemd-delta my-worker.service

它能快速告诉你哪些unit被管理员扩展过、替换过或者被遮蔽过，但拿到这个差异清单之后，还是要回到systemctl cat 和 systemctl show 去核对具体内容。尤其是遇到空的同名覆盖文件、软链接指向/dev/null 做遮蔽、或者多个编号不同的drop-in片段叠加的情况，很容易出现“我明明改了文件”和“服务实际加载的内容完全不一样”的落差。

回滚时只撤掉自己新增的片段

确认问题就是你本次新加的drop-in导致的之后，先把现场留好备份，再移走对应的片段文件：

sudo cp -a /etc/systemd/system/my-worker.service.d/override.conf /tmp/my-worker.override.conf.bak
sudo mv /etc/systemd/system/my-worker.service.d/override.conf /tmp/my-worker.override.conf.disabled
sudo systemctl daemon-reload
sudo systemctl restart my-worker.service
systemctl show my-worker.service -p LimitNOFILE -p DropInPaths

这样既留了可追溯的备份，也不会误删掉发行版自带的原始文件。等验证服务完全恢复到变更前的状态之后，再决定要不要调整数值，或者把这个变更正式纳入配置管理体系里。生产环境绝对不要用直接删整个配置文件夹的方式回滚，文件夹里很可能还存着其他团队之前留下的独立配置片段。

常见问题

cat-config 能直接查看 nginx.service 这类服务unit吗？

查具体服务的unit文件优先用systemctl cat nginx.service。cat-config 更适合查看systemd全局管理器配置和对应配置目录的合并结果。

daemon-reload 执行完之后为什么正在运行的进程参数没有变？

重载动作只会重新读取磁盘上的unit文件，不会主动给已经启动的进程重建资源，要是需要变更启动参数或者资源限制，还要根据业务风险评估执行restart动作，之后再检查服务状态确认生效。

systemctl cat 和 systemctl show 应该优先看哪个？

前者是看所有配置文件的来源和原始写入内容，后者是看systemd解析完成之后输出的最终属性。排查配置不生效的问题的时候，两个命令要配套用，缺一不可。

可以直接修改 /usr/lib/systemd/system 下的unit文件吗？

非常不建议这么做。后续对应软件包升级的时候，自带的unit文件会被直接覆盖，你的改动会直接丢失；本地自定义调整的内容统一放到/etc/systemd/system 路径下的同名unit或者drop-in片段里就好。

把配置文件来源、解析后的属性、重启之后的实际运行状态分开逐层验收，大家遇到systemd“明明写了配置就是不生效”的情况，就能理出一条完全可复查的证据链：先展开完整配置，重载管理器，查看解析后的属性，最后确认服务实际运行状态就好。