在 nginx 中实现平滑重载，核心在于配置 systemd 服务文件中的 reloadsignal 属性并正确设置 execreload。具体做法是在 /etc/systemd/system/nginx.service.d/override.conf 中指定信号类型为 hup，同时在 [service] 部分定义 execreload=/bin/kill -s hup $mainpid。这样当执行 systemctl reload nginx 时，systemd 会向 nginx 主进程发送 sighup 信号，触发其重新加载配置文件而不中断现有连接。
systemd 如何识别并发送重载信号
systemd 通过 ReloadSignal 指令直接映射到特定的 Unix 信号，默认情况下若未显式配置，它可能依赖 ExecReload 命令或尝试使用 SIGHUP。为了明确行为，必须在服务片段中声明 ReloadSignal=HUP。这告诉 systemd 当收到重载请求时，直接向 $MAINPID（即 Nginx master 进程）发送 SIGHUP。Nginx 的主进程接收到该信号后，会启动新的工作进程并优雅地关闭旧的工作进程，从而实现零停机重载。
# /etc/systemd/system/nginx.service.d/override.conf [Service] ExecReload=/bin/kill -s HUP $MAINPID ReloadSignal=HUP
上述配置片段展示了标准的覆盖写法。创建目录 nginx.service.d 后，写入此文件并运行 systemctl daemon-reload 生效。验证方法是通过 systemctl status nginx 查看当前配置是否已应用，或通过 strace -e signal systemctl reload nginx 观察实际发出的信号是否为 SIGHUP。
Nginx 主进程如何处理 SIGHUP 信号
Nginx 的 master 进程在接收到 SIGHUP 后，不会立即重启，而是先解析新的配置文件。如果配置语法检查通过，它会生成新的 worker 进程，这些新进程开始接受新的连接。随后，旧的 worker 进程在处理好所有现有连接后才会退出。这种机制依赖于 Nginx 内部的事件循环和进程管理逻辑，确保在重载期间服务不中断。
# 验证 Nginx 版本及信号支持 nginx -V 2>&1 | grep -o 'built by.*' # 模拟重载过程监控 ps aux | grep nginx kill -HUP $(cat /run/nginx.pid)
通过手动发送 SIGHUP 可以复现 systemd 的行为。观察进程列表变化，可以看到旧的 worker 进程 ID 逐渐消失，新的 worker 进程 ID 出现，而 master 进程 ID 保持不变。这证实了平滑重载的核心是 master 进程的持续存在和 worker 进程的替换。
基于配置文件语法错误的重载失败处理
当 Nginx 配置文件存在语法错误时，接收 SIGHUP 会导致重载失败。此时，Nginx 主进程会在错误日志中记录具体的语法错误位置，并拒绝加载新配置。现有的 worker 进程将继续使用旧的配置处理请求，服务保持正常运行但不会应用任何更改。这是关键的安全机制，防止因配置错误导致服务中断。
# 测试配置文件语法 nginx -t # 查看错误日志确认重载失败原因 tail -f /var/log/nginx/error.log
在实际操作中，执行 systemctl reload nginx 后，应立即检查 error.log。如果看到类似 invalid configuration 的错误，说明重载未成功。此时应修正配置文件，再次运行 nginx -t 确认无误后，重新发起重载请求。这种“先测试后重载”的流程是运维中的标准实践，确保配置的变更是安全的。
