必须执行 systemctl daemon-reload，它强制 systemd 重新加载所有单元文件，使磁盘上修改的服务配置（如 .service 文件或 drop-in 片段）生效；若服务已运行且配置影响启动行为，还需执行 systemctl restart <service>。
改完 /etc/systemd/system/myapp.service 或 drop-in 文件后，服务不生效？直接运行 systemctl daemon-reload 就行——这是唯一标准动作，不执行它，systemd 永远用内存里旧的配置。
为什么改了 .service 文件却没反应？
systemd 启动时把所有 unit 文件一次性加载进内存，后续磁盘上的修改它不会自动感知。你看到的 Warning: myapp.service changed on disk 就是 systemd 在提醒：“我发现了新文件，但我还没认它”。这不是警告你要修什么，而是提示你该手动刷新了。
- 即使服务正在运行，只要改的是
[Unit]或[Install]部分（比如After=、WantedBy=），也必须daemon-reload，否则依赖关系和启用状态不会更新 - 如果只改了
[Service]里的Environment=或RestartSec=，reload 后也不会立刻生效——这些值只在下次启动时读取，得配合systemctl restart myapp -
systemctl enable myapp或disable内部其实也调用了daemon-reload，但手动改文件后这步不会自动触发
daemon-reload 和 reload 的区别别搞混
systemctl daemon-reload 是刷新 systemd 自己的配置缓存；而 systemctl reload myapp 是让正在运行的 myapp 进程自己重读配置（比如 Nginx 的 nginx.conf）。两者完全不冲突，但作用对象不同。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 改的是
.service文件本身 → 必须daemon-reload - 改的是服务自己的配置（如
/etc/nginx/nginx.conf）→ 优先试systemctl reload nginx，失败再restart - 两者都改了？先
daemon-reload，再reload或restart，顺序不能反 -
daemon-reload不会报错，也不输出成功提示，静默完成即代表 OK；可用systemctl cat myapp确认看到的是最新内容
哪些情况改完 service 文件后还必须 restart？
daemon-reload 只让 systemd “知道”新配置，但不会主动应用到已运行的服务进程上。某些变更必须重启才能落地：
-
ExecStart=命令本身被修改（比如路径、参数、环境变量） -
User=、Group=、WorkingDirectory=等影响进程启动上下文的字段 -
Type=forking且服务未正确实现 PID 文件跟踪时，reload 可能根本不起作用 - 服务本身不支持平滑 reload（比如多数自研 Python/Go 服务），
systemctl reload实际会被 systemd 当作restart处理，但前提是daemon-reload已先执行
最容易被忽略的一点：drop-in 片段（/etc/systemd/system/myapp.service.d/override.conf）也是 service 配置的一部分，修改后同样要 daemon-reload，而不是只改主文件才需要。
