nginx工作进程逃脱了master控制

前言

有天接收到业务同事反映，说有些业务超时比例过高。我尝试查询问题，最终定位到nginx将一些请求反向代理到错误的路径上，导致超时。

问题追踪

我准备从以下线索追踪问题：

• 反向代理到的错误路径，这个错误的路径之前是做什么业务。
• 反向代理的配置是否正确
• nginx配置生效操作是否正确

1.错误的路径

这个路径指向的服务器是之前业务的负载，由于这个机器比较就，就将他下架了。此服务器上已经没有相关业务程序，如果有实时请求反向代理到这台机器上，由于该服务器没有部署相关业务程序，请求失败

2.反向代理的配置是否正确

我们观察了upstream相关配置，的确没有配置转发到这台旧机器的配置。

3.nginx配置生效操作是否正确

使用的命令是：

1. nginx -t
2. nginx -s reload

先检查配置是否正确，然后重载。

nginx的reload命令做的是什么样的操作。

参考官方文档

http://nginx.org/en/docs/beginners_guide.html

一旦master 进程接收到需要重载配置文件的信号时，它会检查新配置文件中语法是否正确，尝试着适用该配置。如果成功，master进程会启动新的工作进程，并且向旧的工作进程发送关闭信号，请求关闭旧工作线程。否则，master进程回滚到改动之前的配置状态，继续使用旧的配置文件。老的工作线程，接收到需要关闭的信号时，停止接收新的连接，并且继续服务当前的请求，直到这些请求全部被处理。最后，老的工作线程退出。

回想到错误现象：nginx将一些请求反向代理到错误的路径上，导致超时

存在一些请求反向代理到错误的路径，但是大多数请求的反向代理都是正确的。是不是有些工作进程使用的是当前的配置文件，而有一些工作进程使用的是旧的配置文件。那些走旧的配置文件的工作进程将请求反向代理到错误的路径上。

实际是检验真理的唯一道路，我们登陆服务器查询下该nginx下的工作进程:

 

nginxbug1.png

 

nginxbug3.png

发现果然有一个工作进程的创建时间是2018年，明显有问题。pid为 36766 的nginx master下有一个pid为30284 工作进程的创建时间是 2018年。

问题总结

nginx master 下的 有一个工作进程逃脱了 其的控制，master在做reload操作时，逃脱的工作进程不听master的话，导致的结果就是 有些请求的反向代理到错误的路径上。

后记

nginx是最常用的反向代理工具，熟悉它内在的工作方式很重要。这正是我欠缺的，继续学习吧。

转载于:https://my.oschina.net/huaxiaoqiang/blog/3076048