运行和控制Nginx

Nginx命令参数

# 当前位置
[root@localhost sbin]# pwd
/usr/local/nginx/nginx-1.4.2/sbin
# 缺省的方式启动 Nginx
./nginx
# 为 Nginx 指定一个配置文件，来代替缺省的
./nginx -c </path/nginx.cnof>
# 不运行，仅测试配置文件
./nginx -t
# 显示 nginx 的版本
./nginx -v
# 显示 nginx 的版本，编译器版本和配置参数
./nginx -V
# 快速停止
./nginx -s stop
# 优雅停机
./nginx -s quit
# 重新加载配置文件
./nginx -s reload
# 重新打开日志文件（备份之前的日志文件，重建新的日志文件)
./nginx -s reopen

重新打开日志文件

在没有执行./nginx -s reopen之前，即便已经对文件执行了mv命令也只是改变了文件的名称，nginx还是会向新命名的旧文件中照常写入日志数据。原因在于linux系统中，内核是根据文件描述符来找文件的。
当nginx接到reopen信号的时候会重新打开日志文件（重新打开的日志就是配置文件中设置的位置和名称），此时日志便会写入到新建的日志文件中。

使用信号系统来控制 Nginx

• nginx从容停止命令- 等所有请求结束后关闭服务

  kill -QUIT <nginx pid>
  

• nginx 快速停止命令- 立刻关闭nginx进程

  kill -TERM <nginx pid>
  

• nginx 强制停止

  kill -9 <nginx pid>
  

  获取进程号pid

  [root@localhost sbin]# ps -ef |grep nginx
  root       1343      1  0 Jun09 ?        00:00:00 nginx: master process ./nginx
  nobody     1344   1343  0 Jun09 ?        00:00:00 nginx: worker process
  

  主进程号：1343；工作进程号：1344

  如果嫌麻烦可以不用查看进程号，直接使用命令进行操作

  kill -QUIT `cat /usr/local/nginx/nginx.pid`
  

  主进程可以处理以下的信号

  信号	描述
  TERM, INT	快速关闭
  QUIT	从容关闭（包括主进程和工作进程）
  HUP	重载配置（用新的配置开始新的工作进程 从容关闭旧的工作进程）
  USR1	重新打开日志文件
  USR2	平滑升级可执行程序
  WINCH	从容关闭工作进程
  QUIT	快速关闭

  工作进程可以处理以下的信号

  信号	描述
  QUIT	从容关闭工作进程
  USR1	重新打开日志文件

Nginx重启命令

简单型 - 先关闭进程，再启动进程

# 关闭进程
kill -QUIT cat /usr/local/nginx/nginx.pid
# 启动进程
./nginx

重新加载配置文件，不重启进程，不会停止处理请求

# 在重载前，要先测试一下配置文件
./nginx -t -c /usr/local/nginx/nginx.conf
# 重新加载配置文件
kill -HUP cat /usr/local/nginx/nginx.pid

当 nginx 接收到 HUP 信号，它会尝试先解析配置文件(如果指定配置文件，就使用指定的， 否则使用默认的)，成功的话，就应用新的配置文件。之后，nginx 运行新的工作进程并从容关闭旧的工作进程。通知工作进程关闭监听 套接字但是继续为当前连接的客户提供服务。所有客户端的服务完成后，旧的工作进程被关 闭。 如果新的配置文件应用失败，nginx 将继续使用旧的配置进行工作。

平滑升级到新的二进制代码

可以在不中断服务的情况下 ，使用新的 nginx 可执行程序替换旧的，一般当升级新版本或需要添加/删除服务器模块时使用

• 备份可执行程序

  cp -r nginx-1.4.2/ nginx-1.4.2-copy/
  

• 使用新的可执行程序替换旧的
• 平滑升级可执行程序

  kill -USR2 cat /usr/local/nginx/nginx.pid
  

  此时主进程将重命名它的 .pid 文件为 .oldbin (比如：/usr/local/nginx/nginx.pid.oldbin)，然后执行新的可执行程序，依次启动新的主进程和新的工作进程

  [root@localhost sbin]# ps -ef |grep nginx
  [root@localhost sbin]# ps -ef |grep nginx
  root       1343      1  0 Jun09 ?        00:00:00 nginx: master process ./nginx
  nobody     1344   1343  0 Jun09 ?        00:00:00 nginx: worker process
  root       1441      1  0 Jun09 ?        00:00:00 nginx: master process ./nginx
  nobody     1442   1343  0 Jun09 ?        00:00:00 nginx: worker process
  

  此两个 nginx 实例会同时运行，一起处理输入的请求。要逐步停止旧的实例

• 从容关闭工作进程

  kill -WINCH <old nginx pid>
  
  [root@localhost sbin]# ps -ef |grep nginx
  root       1343      1  0 Jun09 ?        00:00:00 nginx: master process ./nginx
  nobody     1344   1343  0 Jun09 ?        00:00:00 nginx: worker process is shutting down
  root       1441      1  0 Jun09 ?        00:00:00 nginx: master process ./nginx
  nobody     1442   1343  0 Jun09 ?        00:00:00 nginx: worker process
  
  # 一段时间后，旧的工作进程处理了所有已连接的请求后退出，就仅由新的工作进程来处理输入的请求了
  [root@localhost sbin]# ps -ef |grep nginx
  root       1343      1  0 Jun09 ?        00:00:00 nginx: master process ./nginx
  root       1441      1  0 Jun09 ?        00:00:00 nginx: master process ./nginx
  nobody     1442   1343  0 Jun09 ?        00:00:00 nginx: worker process
  

  此时旧的服务器还尚未关闭它监听的套接字，所以仍可以恢复旧的服务器
• 恢复旧服务器

  #发送HUP信号给旧的主进程 - 它将在不重载配置文件的情况下启动它的工作进程
  kill -HUP <old nginx pid>
  #发送QUIT信号给新的主进程，要求其从容关闭其工作进程
  kill -QUIT <new nginx pid>
  #发送TERM信号给新的主进程，迫使其退出
  kill -TERM <new nginx pid>
  #如果因为某些原因新的工作进程不能退出，可以强制退出
  kill -9 <new nginx pid>
  

  新的主进程退出后，旧的主进程会由移除 .oldbin 前缀，恢复为它的 .pid 文件，这样，一切 就都恢复到升级之前了
• 退出旧服务器

  #发送 QUIT 信号给旧的主进程使其退出
  kill -QUIT <old nginx pid>
  
  [root@localhost sbin]# ps -ef |grep nginx
  root       1441      1  0 Jun09 ?        00:00:00 nginx: master process ./nginx
  nobody     1442   1343  0 Jun09 ?        00:00:00 nginx: worker process