修改systemd服务文件后daemon-reload无效，根本原因是systemd加载了/run或/var/run下的缓存副本或drop-in覆盖；需用systemctl cat确认实际加载路径，检查drop-in、Alias、Type配置，并用systemd-analyze verify验证语法。
修改 systemd 服务文件后 systemctl daemon-reload 没用？
常见现象是改了 /etc/systemd/system/myapp.service，执行了 systemctl daemon-reload，但 systemctl show myapp 或重启服务后配置项（比如 Environment=、ExecStart=）仍是旧值。
根本原因通常是：systemd 加载的是缓存副本，而非你正在编辑的文件。它会优先读取 /run/systemd/system/ 或 /var/run/systemd/system/ 下的生成式单元文件（尤其当服务由 generator 生成或被 drop-in 覆盖时）。
- 先运行
systemctl cat myapp，确认实际加载的是哪个路径下的文件（注意输出顶部的 “Loaded:” 行） - 如果显示加载的是
/run/systemd/system/myapp.service，说明有 generator 或临时覆盖，直接编辑/etc/systemd/system/下的文件无效 - 检查是否存在 drop-in 目录：
/etc/systemd/system/myapp.service.d/*.conf，它们的优先级高于主文件，会覆盖同名字段 - 确认没在
.service文件里误写Alias=或WantedBy=导致 unit 名称被重定向
systemctl restart 后进程环境变量还是旧的？
systemd 不会把已启动进程的环境变量“热更新”进去，restart 是杀掉旧进程、用新配置拉起新进程 —— 但如果你用的是 fork+daemonize 模式（比如传统 SysV 风格的守护进程），主进程可能立刻退出，子进程脱离 systemd 管控，后续就不再受其环境或资源限制约束。
- 检查服务是否设置了
Type=forking，且正确声明了PIDFile=；否则 systemd 无法跟踪真正的工作进程 - 更推荐改用
Type=simple（默认）或Type=notify，避免 fork 分离 - 验证环境变量是否生效：用
systemctl show --property=Environment myapp查看 systemd 解析后的值，再用cat /proc/$(pidof myapp)/environ | tr '\0' '\n'看实际进程看到的环境 - 注意
EnvironmentFile=中的变量不会自动导出到 shell 子进程，需显式Environment=FOO=$FOO才能透传
配置改了但日志里看不到变化？
日志内容不更新，往往不是配置没生效，而是 journal 没刷新、或服务根本没按预期重载配置 —— 尤其对那些支持运行时重载（如 nginx -s reload、redis-cli CONFIG REWRITE）但未集成到 systemd 的服务。
- 确认服务是否真的重启了：
systemctl status myapp看 Active 时间戳和 Main PID 是否变化 - journal 默认只保留近期日志，旧条目可能已被轮转清除；加
--all或指定时间范围：journalctl -u myapp --since "2024-05-01" - 如果服务自身支持重载信号（如 SIGHUP），但 unit 文件里没配
ExecReload=，那么systemctl reload实际什么也没做 - 某些服务（如 rsyslog）会监听配置变更并自动重载，但 systemd 并不感知，此时需手动触发或改用
systemctl kill --signal=SIGHUP myapp
SELinux 或 Capabilities 导致配置被静默忽略？
看起来一切正常：文件改了、reload 成功、restart 也成功，但服务行为异常（比如无法绑定端口、读不到配置文件），且 journal 里没有明显报错 —— 这很可能是 SELinux 策略或 capability 限制让 systemd 解析或传递配置失败。
- 检查 SELinux 状态：
sestatus，若为 enforcing，临时设为 permissive：sudo setenforce 0，再试一次，看问题是否消失 - 查看拒绝日志：
sudo ausearch -m avc -ts recent | audit2why，常会暴露类似 “avc: denied { read } for pid=1234 comm="myapp" name="myapp.conf" dev="sda1" ino=56789" 的记录 - Capability 如
CAP_NET_BIND_SERVICE若未在Capabilities=中声明，即使配置写了Port=80，进程也无法真正绑定 - 注意：
PrivateTmp=yes会让服务看到的是独立 tmpfs，你放在/tmp/下的调试文件它根本看不到
最易被忽略的一点：systemd 单元文件语法错误不会导致 reload 失败，而是静默跳过该 unit —— 所以务必用 systemd-analyze verify /etc/systemd/system/myapp.service 检查语法，别只信 daemon-reload 的返回码。
