Nginx信号集有什么用

本篇内容介绍了“Nginx信号集有什么用”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

创新互联基于成都重庆香港及美国等地区分布式IDC机房数据中心构建的电信大带宽，联通大带宽，移动大带宽，多线BGP大带宽租用,是为众多客户提供专业四川主机托管报价，主机托管价格性价比高，为金融证券行业服务器托管，ai人工智能服务器托管提供bgp线路100M独享，G口带宽及机柜租用的专业成都idc公司。

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

前言

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

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

场景复现

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

首先启动 Nginx：

alex@Fedora26-64: ~/bin_install/nginx ./sbin/nginx alex@Fedora26-64: ~/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核心收到这个信号后，就会触发热更新。

alex@Fedora26-64: ~/bin_install/nginx kill -USR2 6174 alex@Fedora26-64: ~/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 进程就会退出：

alex@Fedora26-64: ~/bin_install/nginx kill -WINCH 6174 alex@Fedora26-64: ~/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 命令：

alex@Fedora26-64: ~/bin_install/nginx ./sbin/nginx -s stop alex@Fedora26-64: ~/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[1] 。

Nginx信号集

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

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

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

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

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 这个系统调用，使用新的 NginxELF 文件替换当前的进程映像，成为新的 master 进程。新 master 进程起来之后，就会进行配置文件解析等操作，然后 fork 出新的 worker 进程开始工作。

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

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

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

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

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

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

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

“Nginx信号集有什么用”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！