从实战出发，谈谈 nginx 信号集

Posted 2020-10-16 又拍云

前言

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

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

场景复现

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

首先启动 nginx

[email protected]: ~/bin_install/nginx
./sbin/nginx
[email protected]: ~/bin_install/nginx
ps auxf | grep nginx
alex      6174  0.0  0.0  28876   428 ?        Ss   14:35   0:00 nginx: master process ./sbin/nginx
alex      6175  0.0  0.2  29364  2060 ?        S    14:35   0:00  \_ nginx: worker process

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

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

[email protected]: ~/bin_install/nginx
kill -USR2 6174
[email protected]: ~/bin_install/nginx
ps auxf | grep nginx
alex      6174  0.0  0.1  28876  1996 ?        Ss   14:35   0:00 nginx: master process ./sbin/nginx
alex      6175  0.0  0.2  29364  2060 ?        S    14:35   0:00  \_ nginx: worker process
alex      6209  0.0  0.2  28876  2804 ?        S    14:37   0:00  \_ nginx: master process ./sbin/nginx
alex      6213  0.0  0.1  29364  2004 ?        S    14:37   0:00      \_ nginx: worker process

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

[email protected]: ~/bin_install/nginx
kill -WINCH 6174
[email protected]: ~/bin_install/nginx
ps auxf | grep nginx
alex      6174  0.0  0.1  28876  1996 ?        Ss   14:35   0:00 nginx: master process ./sbin/nginx
alex      6209  0.0  0.2  28876  2804 ?        S    14:37   0:00  \_ nginx: master process ./sbin/nginx
alex      6213  0.0  0.1  29364  2004 ?        S    14:37   0:00      \_ nginx: worker process

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

接着我们使用 stop 命令：

[email protected]: ~/bin_install/nginx
./sbin/nginx -s stop
[email protected]: ~/bin_install/nginx
ps auxf | grep nginx
alex      6174  0.0  0.1  28876  1996 ?        Ss   14:35   0:00 nginx: master process ./sbin/nginx
alex      6301  0.0  0.2  29364  2124 ?        S    14:49   0:00  \_ nginx: worker process

我们会发现，新的 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。

吸收了这个教训之后，我们需要更加合理地关闭我们的 nginx 服务。 所以一个更加合理的 nginx 服务启动关闭脚本是必需的，网上流传的一些脚本并没有对这个现象做处理，我们更应该参考 NGINX 官方提供的脚本。

stop() {
    echo -n $"Stopping $prog: "
    killproc $prog -QUIT
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile
    return $retval
}

　　

这段代码引自 NGINX 官方的 /etc/init.d/nginx 。

nginx 信号集

接下来我们来全面梳理下 nginx 信号集，这里不会涉及到源码细节，感兴趣的同学可以自行阅读相关源码。

我们有两种方式来向 master 进程发送信号，一种是通过 nginx -s signal 来操作，另一种是通过 kill 命令手动发送。

第一种方式的原理是，产生一个新进程，该进程通过 nginx.pid 文件得到 master 进程的 pid，然后把对应的信号发送到 master，之后退出，这种进程被称为 signaller。

第二种方式要求我们了解 nginx -s signal 到真实信号的映射。下表是它们的映射关系：

operationsignalreloadSIGHUPreopenSIGUSR1stopSIGTERMquitSIGQUIThot updateSIGUSR2 & SIGWINCH & SIGQUIT

stop vs quit

stop 发送 SIGTERM 信号，表示要求强制退出，quit 发送 SIGQUIT，表示优雅地退出。 具体区别在于，worker 进程在收到 SIGQUIT 消息（注意不是直接发送信号，所以这里用消息替代）后，会关闭监听的套接字，关闭当前空闲的连接（可以被抢占的连接），然后提前处理所有的定时器事件，最后退出。没有特殊情况，都应该使用 quit 而不是 stop。

reload

master 进程收到 SIGHUP 后，会重新进行配置文件解析、共享内存申请，等一系列其他的工作，然后产生一批新的 worker 进程，最后向旧的 worker 进程发送 SIGQUIT 对应的消息，最终无缝实现了重启操作。

reopen

master 进程收到 SIGUSR1 后，会重新打开所有已经打开的文件（比如日志），然后向每个 worker 进程发送 SIGUSR1 信息，worker 进程收到信号后，会执行同样的操作。reopen 可用于日志切割，比如 NGINX 官方就提供了一个方案：

$ mv access.log access.log.0
$ kill -USR1 `cat master.nginx.pid`
$ sleep 1
$ gzip access.log.0    # do something with access.log.0

　　

这里 sleep 1 是必须的，因为在 master 进程向 worker 进程发送 SIGUSR1 消息到 worker 进程真正重新打开 access.log 之间，有一段时间窗口，此时 worker 进程还是向文件 access.log.0 里写入日志的。通过 sleep 1s，保证了 access.log.0 日志信息的完整性（如果没有 sleep 而直接进行压缩，很有可能出现日志丢失的情况）。

hot update

某些时候我们需要进行二进制热更新，nginx 在设计的时候就包含了这种功能，不过无法通过 nginx 提供的命令行完成，我们需要手动发送信号。

通过上面的问题复现，大家应该已经了解到如何进行热更新了，我们首先需要给当前的 master 进程发送 SIGUSR2，之后 master 会重命名 nginx.pid 到 nginx.pid.oldbin，然后 fork 一个新的进程，新进程会通过 execve 这个系统调用，使用新的 nginx ELF 文件替换当前的进程映像，成为新的 master 进程。新 master 进程起来之后，就会进行配置文件解析等操作，然后 fork 出新的 worker 进程开始工作。

接着我们向旧的 master 发送 SIGWINCH 信号，然后旧的 master 进程则会向它的 worker 进程发送 SIGQUIT 信息，从而使得 worker 进程退出。向 master 进程发送 SIGWINCH 和 SIGQUIT 都会使得 worker 进程退出，但是前者不会使得 master 进程也退出。

最后，如果我们觉得旧的 master 进程使命完成，就可以向它发送 SIGQUIT 信号，让其退出了。

worker 进程如何处理来自 master 的信号消息

实际上，master 进程再向 worker 进程通讯，不是使用 kill 函数，而是使用了通过管道实现的 nginx channel，master 进程向管道一端写入信息（比如信号信息），worker 进程则从另外一端收取信息，nginx channel 事件，在 worker 进程刚刚起来的时候，就被加入事件调度器中（比如 epoll，kqueue），所以当有数据从 master 发来时，即可被事件调度器通知到。

nginx 这么设计是有理由的，作为一个优秀的反向代理服务器，nginx 追求的就是极致的高性能，而 signal handler 会中断 worker 进程的运行，使得所有的事件都被暂停一个时间窗口，这对性能是有一定损失的。

很多人可能会认为当 master 进程向 worker 进程发送信息之后，worker 进程立刻会有对应操作回应，然而 worker 进程是非常繁忙的，它不断地处理着网络事件和定时器事件，当调用 nginx channel 事件的 handler 之后，nginx 仅仅只是处理了一些标志位。真正执行这些动作是在一轮事件调度完成之后。所以这之间存在一个时间窗口，尤其是业务复杂且流量巨大的时候，这个窗口就有可能被放大，这也就是为什么 NGINX 官方提供的日志切割方案里要求 sleep 1s 的原因。

当然，我们也可以绕过 master 进程，直接向 worker 进程发送信号，worker 可以处理的信号有

signaleffectSIGINT强制退出SIGTERM强制退出SIGQUIT优雅退出SIGUSR1重新打开文件

总结

nginx 信号操作在日常运维中是最常见的，也是非常重要的，这个环节如果出现失误则可能造成业务异常，带来损失。所以理清楚 nginx 信号集是非常必要的，能帮助我们更好地处理这些工作。

另外，通过这次的经验教训和对 nginx 信号集的认知，我们认为以下几点是比较重要的：

• 慎用 nginx -s stop，尽可能使用 nginx -s quit
• 热更新之后，如果确定业务没问题，尽可能让旧的 master 进程退出
• 关键性的信号操作完成后，等待一段时间，避免时间窗口的影响
• 不要直接向 worker 进程发送信号

 

推荐阅读：

启用 Brotli 压缩算法，对比 Gzip 压缩 CDN 流量再减少 20%

HTTPS 传输优化详解之动态 TLS Record Size