为什么要 daemon-reload
systemd 在启动时把单元文件解析进内存并缓存下来，之后运行全靠这份缓存。你改了单元文件、加了片段或调整了依赖，磁盘上是新的，但内存里还是旧的，必须让 systemd 重新读取才会看到变化——这个动作就是 daemon-reload。它只重读定义，不会重启任何服务，也不会让运行中的进程读到新的环境变量或资源上限，那些改动还要靠重启服务才落地。这也是「配置改了没生效」类问题最常见的原因之一。
基本信息
| 命令 | systemctl daemon-reload |
|---|---|
| 作用范围 | 重新读取全部单元文件与片段定义 |
| 是否重启服务 | 否，运行中的进程不受影响 |
| 适用场景 | 新增单元、修改单元、增删覆盖片段、调整依赖关系 |
| 不适用场景 | 只改程序自身的配置文件 |
| 适用平台 | Kylin V10 / UOS 服务器版 / openEuler 等 systemd 系统 |
典型使用场景
- 新写单元文件后首次启用：不重载则列表里看不到新单元
- 调整重启策略或资源上限：必须重载再重启，否则沿用旧定义
- 增加覆盖片段：片段是定义的一部分，同样需要重载
- 调整依赖顺序：依赖关系在加载阶段解析，改了就要重载
- 批量变更脚本化：把重载、重启、验证固定成三步动作
- 变更后核对：重载后查看实际生效值，确认与预期一致
标准动作
标准动作
systemctl daemon-reload # 重新读取单元定义
systemctl restart myapp # 让新的进程参数生效
systemctl show myapp -p Restart -p User -p Environment # 核对实际生效值
systemctl status myapp --no-pager | head -12 # 确认状态正常
journalctl -u myapp -n 50 --no-pager # 有异常时看日志改什么要做什么
| 改动内容 | 需要重载 | 需要重启 |
|---|---|---|
| 单元文件里的启动命令 | 需要 | 需要 |
| 环境变量与资源上限 | 需要 | 需要 |
| 覆盖片段 | 需要 | 需要 |
| 依赖与排序关系 | 需要 | 按依赖情况处理 |
| 仅单元描述文字 | 需要 | 不需要 |
| 程序自身的配置文件 | 不需要 | 看是否支持在线重载 |
两个命令名字相近但作用完全不同：重载单元定义负责让系统看到新配置，重载服务负责让进程重读它自己的配置文件。前者不碰进程，后者由服务实现决定是否支持，混用会造成「改了没反应」或「该重启却只重载」。
重载只更新定义，不会中断业务；但要落实新参数必然要重启服务，而重启会断开现有连接。数据库、网关类服务应先确认维护窗口，能在不中断的前提下生效的改动优先选在线重载方式。