这篇文章中,提到了Master进程对信号的处理函数,其中有两个信号比较有意思。
SIGHUP:用来热更新(Reload)应用
SIGUSR2:用来在线升级(upgrade on the fly)gunicorn
 
下面来详细看一下:
 
SIGHUP
    Reload the configuration, start the new worker processes with a new configuration and gracefully shutdown older workers. 
SIGUP对应的信号处理函数是Arbiter.reload。简化后的核心代码如下:
     def reload(self):
old_address = self.cfg.address # reload conf,重新加载配置
self.app.reload()
self.setup(self.app) # reopen log files
self.log.reopen_files() # do we need to change listener ?,处理监听端口变化的情况
if old_address != self.cfg.address:
# close all listeners
[l.close() for l in self.LISTENERS]
# init new listeners
self.LISTENERS = create_sockets(self.cfg, self.log)
listeners_str = ",".join([str(l) for l in self.LISTENERS])
self.log.info("Listening at: %s", listeners_str) # spawn new workers,启动新的Worker(数量和类型来自新的配置)
for i in range(self.cfg.workers):
self.spawn_worker() # manage workers,这里会kill掉原来的Worker
self.manage_workers()
  在上面的引用中提到,会“优雅”(graceful)地kill掉老的worker进程。实现也很简单,Arbiter为每一个fork出的worker进程设置一个自增的“worker_age”,worker中这个属性越小,表明这个worker越老。在manage_workers中,如果已经启动的worker进程数量大于配置中的数量,那么会kill掉比较老的worker进程。代码如下
     def manage_workers(self):
"""\
Maintain the number of workers by spawning or killing
as required.
"""
if len(self.WORKERS.keys()) < self.num_workers:
self.spawn_workers() workers = self.WORKERS.items()
workers = sorted(workers, key=lambda w: w[1].age) # 按worker的age顺序排序
while len(workers) > self.num_workers: # num_workers是配置的worker数量
(pid, _) = workers.pop(0)
self.kill_worker(pid, signal.SIGTERM)
SIGUSR2
Upgrade the Gunicorn on the fly. A separate TERM signal should be used to kill the old process.
  对应的信号处理函数是Arbiter.reexec,该函数会重新fork出新的master-workers进程,但不会影响到原来的master,worker进程,所以上面提到需要将原来的进程kill掉。
     def reexec(self):
"""\
Relaunch the master and workers.
"""
if self.reexec_pid != 0:
self.log.warning("USR2 signal ignored. Child exists.")
return if self.master_pid != 0:
self.log.warning("USR2 signal ignored. Parent exists")
return master_pid = os.getpid()
self.reexec_pid = os.fork()
if self.reexec_pid != 0:
return self.cfg.pre_exec(self) environ = self.cfg.env_orig.copy()
fds = [l.fileno() for l in self.LISTENERS]
environ['GUNICORN_FD'] = ",".join([str(fd) for fd in fds]) # 设置了一些环境变量,用来区分是正常启动gunicorn还是通过fork重新启动。
environ['GUNICORN_PID'] = str(master_pid) os.chdir(self.START_CTX['cwd']) # exec the process using the original environnement
os.execvpe(self.START_CTX[0], self.START_CTX['args'], environ)
下面做一下实验,两个终端,1号终端运行代码,2号终端发送信号。
step1
1号终端启动gunirorn: gunicorn -w 2 gunicorn_app:app ,
2号终端查看python进程: ps -ef | grep python,
 
1号终端输出
[2017-01-19 15:21:23 +0000] [6166] [INFO] Starting gunicorn 19.6.0
[2017-01-19 15:21:23 +0000] [6166] [INFO] Listening at: http://127.0.0.1:8000 (6166)
[2017-01-19 15:21:23 +0000] [6166] [INFO] Using worker: sync
[2017-01-19 15:21:23 +0000] [6171] [INFO] Booting worker with pid: 6171
[2017-01-19 15:21:23 +0000] [6172] [INFO] Booting worker with pid: 6172
 
2号终端输出
hzliumi+  6166  5721  0 15:21 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
hzliumi+  6171  6166  0 15:21 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
hzliumi+  6172  6166  0 15:21 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
 
可以看到,master进程的PID是6166,然后两个worker进程的pid分别是6171、6172. 下面需要用到master进程的PID
 
step2
2号终端发送信号:kill -SIGUSR2 6166 , 然后查看python进程
 
1号终端追加输出
[2017-01-19 15:27:08 +0000] [6166] [INFO] Handling signal: usr2
[2017-01-19 15:27:08 +0000] [6629] [INFO] Starting gunicorn 19.6.0
[2017-01-19 15:27:08 +0000] [6629] [INFO] Listening at: http://127.0.0.1:8000 (6629)
[2017-01-19 15:27:08 +0000] [6629] [INFO] Using worker: sync
[2017-01-19 15:27:08 +0000] [6634] [INFO] Booting worker with pid: 6634
[2017-01-19 15:27:08 +0000] [6635] [INFO] Booting worker with pid: 6635
 
2号终端输出
hzliumi+  6166  5721  0 15:21 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
hzliumi+  6171  6166  0 15:21 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
hzliumi+  6172  6166  0 15:21 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
hzliumi+  6629  6166  3 15:27 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
hzliumi+  6634  6629  0 15:27 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
hzliumi+  6635  6629  0 15:27 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
 
从1号终端可以看出,基本是重新启动了gunicorn,不过从2号终端输出可以看到,新的master进程(pid 6629)是老的master进程(pid 6166)的子进程
 
step3
    2号终端发送信号:kill -SIGTERM 6166 , 稍等几秒后查看python进程:
 
1号终端追加输出
[2017-01-19 15:29:42 +0000] [6166] [INFO] Handling signal: term
[2017-01-19 15:29:42 +0000] [6171] [INFO] Worker exiting (pid: 6171)
[2017-01-19 15:29:42 +0000] [6172] [INFO] Worker exiting (pid: 6172)
[2017-01-19 15:29:42 +0000] [6166] [INFO] Shutting down: Master
[2017-01-19 15:29:42 +0000] [6629] [INFO] Master has been promoted.
 
2号终端输出
hzliumi+  6629     1  0 15:27 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
hzliumi+  6634  6629  0 15:27 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
hzliumi+  6635  6629  0 15:27 pts/0    00:00:00 /usr/bin/python /usr/local/bin/gunicorn -w 2 gunicorn_app:app
 
可以看到,老的master进程(6166)及其fork出的worker子进程(pid分别是6171、6172)已经被kill掉了
 
 
 
references:

gunicorn 信号处理(SIGHUP,SIGUSR2)的更多相关文章

  1. [10]APUE:信号

    [a] 常用信号 SIGABRT 调用 abort 函数时产生此信号,进程异常终止 SIGALRM 调用 alarm 或 setitimer 函数超时之后产生 SIGCHLD 子进程终止或 stop ...

  2. nginx的平滑升级

    一:解释nginx的平滑升级 随着nginx越来越流行,并且nginx的优势也越来越明显,nginx的版本迭代也来时加速模式,1.9.0版本的nginx更新了许多新功能,例如stream四层代理功能, ...

  3. gunicorn Arbiter 源码解析

    如前文所述,Arbiter是gunicorn master进程的核心.Arbiter主要负责管理worker进程,包括启动.监控.杀掉Worker进程:同时,Arbiter在某些信号发生的时候还可以热 ...

  4. Linux 多线程应用中如何编写安全的信号处理函数

    http://blog.163.com/he_junwei/blog/static/1979376462014021105242552/ http://www.ibm.com/developerwor ...

  5. linux 下信号处理命令trap && linux下各种信号的意义

    1.用途说明 trap是一个shell内建命令,它用来在脚本中指定信号如何处理.比如,按Ctrl+C会使脚本终止执行,实际上系统发送了SIGINT信号给脚本进程,SIGINT信号的默认处理方式就是退出 ...

  6. Perl信号处理

    本文关于Perl信号处理的内容主体来自于<Pro Perl>的第21章. 信号处理 操作系统可以通过信号(signal)处理机制来实现一些功能:程序注册好待监视的信号处理机制,在程序运行过 ...

  7. Android 信号处理面面观 之 信号定义、行为和来源

    总结: Android中: Sending signal. PID: XXX SIG: 3   ====>打印trace 原文:http://blog.csdn.net/rambo2188/ar ...

  8. linux 信号处理 五 (示例)

    [摘要]本文分析了Linux内核对于信号的实现机制和应用层的相关处理.首先介绍了软中断信号的本质及信号的两种不同分类方法尤其是不可靠信号的原理.接着分析了内核对于信号的处理流程包括信号的触发/注册/执 ...

  9. linux 信号处理 一 (基本概念)

    信号是Linux编程中非常重要的部分,本文将详细介绍信号机制的基本概念.Linux对信号机制的大致实现方法.如何使用信号,以及有关信号的几个系统调用. 信号机制是进程之间相互传递消息的一种方法,信号全 ...

随机推荐

  1. Python概述与安装

    Python 一门面向对象的解释性语言. Python优点 开发效率高(有丰富的各种类库,不需要重复造轮子):可移植性:解释性:免费开源:交互式(IDLE,代码写一行执行一行) Python缺点 相对 ...

  2. 聊下 git 多账户问题

    git 多账户问题 标签(空格分隔):git github gitlab git多账户 背景 git 多账号配置 ssh 多密钥对配置 背景 在使用 git 的时候我们都会面临多账户问题,比较常见的就 ...

  3. 《Linux命令行与shell脚本编程大全》第十章 使用编辑器

    主要介绍vim, nano, emacs,KWrite,Kate,GNOME 10.1 vim Unix系统最初的编辑器 10.1.1检查vim软件包 先搞明白你所用的Linux系统是哪种vim软件包 ...

  4. CLR类型设计之泛型(一)

    在讨论泛型之前,我们先讨论一下在没有泛型的世界里,如果我们想要创建一个独立于被包含类型的类和方法,我们需要定义objece类型,但是使用object就要面对装箱和拆箱的操作,装箱和拆箱会很损耗性能,我 ...

  5. 漫淡面向对象——POJO对象

    产品或者服务由数据存储和数据计算组成.pojo对象就是用于数据存储.一旦确定后,整个应用或者产品的数据来源就确定.比如一个页面或者功能需要使用什么数据就可以快速找到对应的对象或者通过对象的关系找出来. ...

  6. SSD中的GC机制以及Trim

    GC(Garbagecollection)垃圾回收  所谓GC就是把一个闪存块里的"有效"页数据复制到一个"空白"块里,然后把这个块完全擦除.GC是 SSD里的 ...

  7. 【Java入门提高篇】Day1 抽象类

    基础部分内容差不多讲解完了,今天开始进入Java提高篇部分,这部分内容会比之前的内容复杂很多,希望大家做好心理准备,看不懂的部分可以多看两遍,仍不理解的部分那一定是我讲的不够生动,记得留言提醒我. 好 ...

  8. jvm内存区域与内存溢出

    java内存 java动态运行时区域包括:方法区.虚拟机栈.本地方法栈.堆.程序计数器,如右图所示:   程序计数器 程序计数器用来标识要执行的代码的行号,为线程私有   虚拟机栈 为线程所私有 虚拟 ...

  9. 关于如何获取移动端 touchmove 事件中真正触摸点下方的元素

    移动端的touchstart, touchmove, touchend三个事件,点击元素并拖动时,获取到了touchmove事件, 但是event.touches[0].target所指向的元素却是t ...

  10. pku夏令营面试

    北大面试题目: 一.内存交换 内存交换(对换)的基本思想是,把处于等待状态(或在CPU调度原则下被剥夺运行权利) 的程序从内存移到辅存,把内存空间腾出来,这一过程又叫换出:把准备好竞争CPU运行的程序 ...