systemd 服务热加载需服务自身支持 sighup 或 reload 命令，否则需用内部命令（如 redis 的 config set、postgresql 的 pg_reload_conf）；验证配置后查 journalctl 日志定位问题。
systemd 服务如何触发配置热加载
大多数 systemd 管理的服务不自动监听配置变化，必须显式通知。核心是让进程收到 SIGHUP 或调用其内置 reload 命令——但前提是该服务真正支持热重载。
常见错误现象：systemctl reload nginx 成功返回，但修改 /etc/nginx/nginx.conf 后请求仍 502；或 systemctl reload sshd 直接报错“Unit not found”。
- 先确认服务是否声明了
Reload指令：systemctl show <service-name> | grep -i reload</service-name>，输出含Reload=/usr/sbin/nginx -s reload才算真支持 - 部分服务（如
sshd）默认禁用 reload，需在/etc/systemd/system/sshd.service.d/override.conf中手动加ExecReload=/usr/sbin/sshd -t && /usr/sbin/sshd -T && /bin/kill -HUP $MAINPID -
systemctl reload不等于systemctl restart：前者不中断连接（如 Nginx 已建立的长连接），后者会断连
程序自身不支持 SIGHUP 怎么办
像 redis-server、postgresql 这类进程，启动后配置即固化，SIGHUP 无效，必须走内部命令或 SQL 接口重新加载。
使用场景：你改了 /etc/redis/redis.conf，但 kill -HUP $(pidof redis-server) 完全没反应。
-
redis-server需用redis-cli CONFIG REWRITE（仅对运行时可改参数生效），或CONFIG SET逐项更新 -
postgresql要执行SELECT pg_reload_conf();，或用pg_ctl reload -D /var/lib/postgresql/data - 切勿直接改
postgresql.conf后kill -HUP：PostgreSQL 忽略该信号，且可能因语法错误导致后续无法启动
自定义脚本热加载 配置文件 的最小可行方案
如果你写了个 Python/Go 小服务，想实现“改 config.toml 后自动生效”，别急着上 inotify + fork，先看是否真需要实时性。
性能影响：轮询检查文件 mtime 每秒一次几乎无开销；用 inotifywait 可靠但增加依赖；用 fanotify 过度设计，普通服务用不上。
- 最简做法：在主循环里加
if os.path.getmtime(config_path) != last_mtime: reload_config(); last_mtime = ……，间隔 1–5 秒足够 - 若用
inotifywait，务必捕获IN_MOVED_TO和IN_CREATE（编辑器常先写临时文件再 mv 覆盖） - 避免 reload 期间出现竞态：新配置加载中，旧配置还在被读取，建议用原子替换全局配置对象（如 Python 的
config = new_config，而非就地修改 dict）
热加载失败时怎么快速定位
错误信息往往藏在服务日志里，而不是 systemctl reload 的终端输出中。
典型坑：nginx -s reload 报 nginx: [emerg] unknown directive "upstream"，但你肉眼检查配置明明没错——其实是 include 的子文件路径错了，或权限不足读不到。
- 始终用验证命令前置：
nginx -t、sshd -t、redis-server --test-memory，再 reload - 查真实日志：
journalctl -u nginx --since "1 minute ago" -n 50，别只信systemctl status的 summary 行 - 注意 SELinux 上下文：
restorecon -Rv /etc/nginx，否则nginx -t可能静默失败
配置热加载不是开关一按就灵的事。它依赖服务本身的设计、信号处理的健壮性、以及你对 reload 边界条件的理解——比如 Nginx reload 失败时，worker 进程仍在用旧配置跑，master 却已退出，这时候 ps aux | grep nginx 看起来一切正常，但新请求进不来。
