daemon-reload 是什么
systemctl daemon-reload 让 systemd 管理器重新读取磁盘上的单元文件。管理器启动服务用的是内存里的单元定义，直接编辑 /etc/systemd/system 下的 .service 文件不会自动生效，必须 reload 让它重新解析并重建依赖关系。它只处理「定义」，既不重启服务、也不重载服务自身的配置，这正是常被和 systemctl reload 混淆的地方：前者针对单元定义，后者针对正在运行的服务进程。因为不停机、开销很小，改完单元就应该立即执行。
基本信息
| 适用平台 | Linux（systemd 管理器的系统） |
|---|---|
| 命令语法 | systemctl daemon-reload |
| 触发时机 | 新建、修改、删除或重命名单元文件；改 drop-in；调整 .wants 目录下的链接 |
| 影响范围 | 不中断服务，几乎无停机成本；运行中的服务仍按旧定义工作，直到下次启动 |
| 验证手段 | systemctl cat 看管理器持有的最终内容、systemd-delta 看被覆盖或修改的单元 |
典型使用场景
- 改完 .service：调整 ExecStart、Restart 或环境变量后让新定义生效
- 新增单元：部署新服务后第一次启动前先 reload
- 改 drop-in 覆盖：给已有单元追加 .conf 覆盖片段后重新解析
- 批量部署：脚本一次性铺好多个单元文件，最后统一 reload 再逐个启动
- 排查「改了没效果」：确认管理器是否读到最新版本
改单元的四步
改单元的四步
vi /etc/systemd/system/myapp.service # 1. 编辑单元
systemctl daemon-reload # 2. 重载定义
systemctl restart myapp # 3. 让新定义生效
systemctl status myapp --no-pager | head -n 5 # 4. 验证
systemctl cat myapp | head -n 20 # 确认管理器看到的最终内容
systemd-delta | head # 查看被覆盖或修改的单元
systemctl daemon-reexec # 需要管理器自身重新执行时使用三种重载的区别
| 命令 | 作用对象 | 是否影响运行中的服务 |
|---|---|---|
| systemctl daemon-reload | 磁盘上的单元定义与依赖关系 | 不影响，下次启动时才使用新定义 |
| systemctl reload myapp | 服务自身的配置（需单元定义 ExecReload） | 不重启进程，由服务自行重读配置 |
| systemctl restart myapp | 服务进程本身 | 会中断并重新拉起，短时不可用 |
| systemctl reload-or-restart | 优先 reload，无 ExecReload 时改为 restart | 取决于单元是否定义了 ExecReload |
daemon-reload 不会重启服务，所以改完 Restart= 或 ExecStart= 之后还要显式 restart 才看得到效果；日志里能看到管理器的重载事件，但不会有服务重启记录。
重命名单元文件前先 systemctl disable 旧名称再删除，否则 /etc/systemd/system/*.wants/ 下残留的软链接会在下次开机时报找不到单元。