Linux 服务为什么重启后配置失效：daemon-reload、enable 与启动状态的排查顺序

改了 /etc/systemd/system/report-sync.service 里的 ExecStart，手动启动看起来正常，机器重启后却像没改过一样，通常不是 Linux “丢配置”，而是几个动作的职责混在了一起。daemon-reload 让管理器重新读取 unit 文件，enable 只负责建立开机启用关系，start 才影响当前运行状态。

排查顺序固定为：先确认文件位置和内容，再执行 daemon-reload，随后分别检查 enable 与当前启动状态；不要把 enable 当成 start，也不要把 reload 当成服务重启。

排查顺序固定为：先执行最小核验命令确认systemd已经加载到新配置，再核对开机自启绑定状态，最后校验服务运行状态，跳过任何一步都很容易出现重启后配置失效的情况。

先把“配置没生效”拆成三个现象

先不要连续执行一串命令。下面三种现象对应不同证据，混查只会把问题越查越乱。

修改 unit 文件后，先完成 daemon-reload

以 report-sync.service 为例，先确认正在编辑的是系统 unit 搜索路径中的文件：

sudo systemctl cat report-sync.service
sudo systemctl daemon-reload
sudo systemctl show report-sync.service -p FragmentPath -p ExecStart

cat 负责看文件来源，daemon-reload 负责让管理器重新扫描并解析 unit，show 则用于确认管理器当前看到的路径和启动命令。这里不要用 systemctl reload report-sync.service 代替：reload 是请求服务自身重载业务配置，不等同于重新读取 unit 文件。

drop-in 文件也要纳入检查

如果配置放在 /etc/systemd/system/report-sync.service.d/override.conf，单看主文件容易误判。再次执行 systemctl cat report-sync.service，确认输出末尾是否包含 drop-in 内容；改完 drop-in 后同样需要 daemon-reload。

把 enable 和 start 分开验证

配置重新载入后，再决定当前是否启动、重启后是否自动启动：

sudo systemctl enable report-sync.service
sudo systemctl start report-sync.service
systemctl is-enabled report-sync.service
systemctl is-active report-sync.service
systemctl status report-sync.service --no-pager

enable 建立开机启动所需的链接关系，start 只处理当前这次启动。两者可以合并成 enable --now，但排查时拆开更容易判断到底是哪一步缺失。最终应看到 is-enabled 返回 enabled，is-active 返回 active；若前者正确而后者失败，问题已经从“开机策略”转到服务自身的启动过程。

用一轮最小复核确认重启后的真实状态

变更完成后可以把核验压缩成下面这一轮。它不依赖模糊的“应该生效”，每一步都有可观察输出：

unit=report-sync.service
systemctl cat "$unit"
systemctl is-enabled "$unit"
systemctl is-active "$unit"
systemctl show "$unit" -p FragmentPath -p ExecStart
systemctl status "$unit" --no-pager

如果重启后 is-enabled 仍是 disabled，补执行 enable；如果 is-enabled 是 enabled 但 is-active 不是 active，查看 status 中的退出原因和最近日志。不要为了让状态变绿而反复 restart，先保留失败现场。

常见误区与回滚边界

只执行 daemon-reload，服务会自动换成新命令吗？

不会。它更新管理器对 unit 的认识；已经运行的进程是否替换，要按需执行 restart，并确认新进程的 ExecStart。

enable 返回成功，为什么当前没有进程？

enable 只表示开机启用关系已建立。当前进程由 start、restart 或开机过程产生，使用 is-active 和 status 单独确认。

改错 unit 文件如何安全退回？

先把改动恢复到已知版本，再执行 daemon-reload，最后按需 restart；如果是 drop-in，优先移走或修正对应的 override.conf，不要删除主 unit 来“碰运气”。

相关问题：重启前还要确认哪些状态

怎么确认当前加载的是哪个 unit 文件？

执行 systemctl show report-sync.service -p FragmentPath，把返回路径与实际编辑文件对照，再检查 drop-in 是否出现在 systemctl cat 输出中。

enable --now 适合直接用于修复吗？

它会同时建立开机启用关系并启动当前服务。故障排查时建议拆开执行，便于知道是启用关系还是启动动作出了问题。

为什么 active 仍不能证明重启后一定会自动启动？

active 只描述当前状态；重启后的自动启动还要看 is-enabled 是否为 enabled，两项都通过才算闭环。

最后的排查清单

• 文件路径：systemctl cat 是否显示了正在编辑的主文件和 drop-in。
• 配置载入：修改后是否执行了 daemon-reload。
• 开机关系：is-enabled 是否为 enabled。
• 当前状态：is-active 是否为 active，失败时是否保留 status 输出。
• 最终内容：show -p FragmentPath -p ExecStart 是否与预期一致。