nginx信号集案例详解

之前工作时候，一台引流测试机器的一个 ngx_lua 服务突然出现了一些 HTTP/500 响应，从错误日志打印的堆栈来看，是不久前新发布的版本里添加的一个 Lua table 不存在，而有代码向其进行索引导致的。这令人百思不得其解，如果是版本回退导致的，那么为什么使用这个 Lua table 的代码没有被回退，偏偏定义这个 table 的代码被回退了呢？

经过排查发现，当时 nginx 刚刚完成热更新操作，旧的 master 进程还存在，因为要准备机器重启，先切掉了引流流量（但有些请求还在），同时系统触发了 nginx -s stop，这才导致了这个问题。

场景复现

下面我将使用一个原生的 nginx，在我的安装了 fedora26 的虚拟机上复现这个过程，我使用的 nginx 版本是目前最新的 1.13.4

首先启动 nginx

可以看到 master 和 worker 都已经在运行。

接着我们向 master 发送一个 SIGUSR2 信号，当 nginx 核心收到这个信号后，就会触发热更新。

可以看到新的 master 和该 master fork 出来的 worker 已经在运行了，此时我们接着向旧 master 发送一个 SIGWINCH 信号，旧 master 收到这个信号后，会向它的 worker 发送 SIGQUIT，于是旧 master 的 worker 进程就会退出：

此时只剩下旧的 master，新的 master 和新 master 的 worker 在运行，这和当时线上运行的情况类似。

接着我们使用 stop 命令：

我们会发现，新的 master 和它的 worker 都已经退出，而旧的 master 还在运行，并产生了 worker 出来。这就是当时线上的情况了。

事实上，这个现象和 nginx 自身的设计有关：当旧的 master 准备产生 fork 新的 master 之前，它会把 nginx.pid 这个文件重命名为 nginx.pid.oldbin，然后再由 fork 出来的新的 master 去创建新的 nginx.pid，这个文件将会记录新 master 的 pid。nginx 认为热更新完成之后，旧 master 的使命几乎已经结束，之后它随时会退出，因此之后的操作都应该由新 master 接管。当然，在旧 master 没有退出的情况下通过向新 master 发送 SIGUSR2 企图再次热更新是无效的，新 master 只会忽略掉这个信号然后继续它自己的工作。

问题分析

更不巧的是，我们上面提到的这个 Lua table，定义它的 Lua 文件早在运行 init_by_lua 这个 hook 的时候，就已经被 LuaJIT 加载到内存并编译成字节码了，那么显然旧的 master 必然没有这个 Lua table，因为它加载那部分 Lua 代码是旧版本的。

而索引该 table 的 Lua 代码并没有在 init_by_lua 的时候使用到，这些代码都是在 worker 进程里被加载起来的，这时候项目目录里的代码都是最新的，所以 worker 进程加载的都是最新的代码，如果这些 worker 进程处理到相关的请求，就会出现 Lua 运行时错误，外部表现则是对应的 HTTP 500。