用信号做热加载
多数服务支持在不中断业务的前提下重新读取配置：做法是给它发一个约定的信号，进程收到后重新解析配置文件、平滑替换工作进程。不同应用约定的信号不同，常见的是 HUP、USR1、USR2 与 QUIT。正确姿势是先做配置语法校验，再发信号，最后验证新配置确实生效，而不是盲发。
基本信息
| 典型场景 | 改完配置不想重启进程，避免连接中断与启动耗时 |
|---|---|
| 通用流程 | 配置校验 → 发信号或调用服务的 reload → 验证生效 |
| systemd 环境 | 优先 systemctl reload，它封装了正确信号与前置校验 |
| 风险点 | 发错信号可能直接终止进程，也可能让配置只生效一半 |
典型使用场景
- 调整负载均衡后端列表后平滑生效，不丢在途请求
- 修改日志级别或日志路径，让进程重新打开日志文件
- 轮转日志后通知进程切换写入新的文件句柄
- 灰度发布时先在一台机器上验证配置再推其余节点
- 二进制热升级场景由旧进程移交监听套接字给新进程
通用流程
通用流程
nginx -t # 1. 配置语法校验（各应用命令不同）
kill -HUP $(cat /run/nginx.pid) # 2. 发重载信号（示例：nginx 用 HUP）
ps -o etime= -p $(cat /run/nginx.pid) # 3. 进程没重启，运行时长没归零
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1/health # 4. 业务探活
sudo systemctl reload nginx # 有 systemd 时优先用它
journalctl -u nginx -n 30 --no-pager # 5. 看日志确认没有解析报错常用信号读法
| 信号 | 常见语义 | 注意 |
|---|---|---|
| HUP | 重读配置（多数服务约定） | 有些服务收到 HUP 会直接退出，先查文档 |
| USR1 | 因应用而异：重开日志、切换状态输出等 | 同一信号在不同应用语义完全不同 |
| USR2 | 升级二进制或重新执行自身 | 以 nginx 类应用为例，用于平滑升级 |
| QUIT | 优雅退出 | 会停止服务，别当成重载 |
| TERM | 请求终止 | 默认的停止信号，不是重载 |
systemd 环境优先用 systemctl reload：它把正确信号、前置校验与失败处理都封装好了，比手工查表发信号更不容易出错。
验证重载成功不能只看命令返回，要同时确认进程运行时长没归零（说明没重启）、日志没有解析报错、健康检查正常。