深入 superviser
模块简介
新人接触线上的时候一般都会碰到supervise这个工具,导师对这个模块的解释一般就是,这个模块是监控进程,当进程挂掉之后,supervise会将进程启动。这样当进程出
现问题,如因出core而导致进程down掉的时候,supervise会马上将进程起起来,从而快速恢复服务。
新人一般就会记住这一点,然后就一直没有去深入理解,supervise具体是怎么做的这一点的,以及从supervise我们能获得什么信息。
实际上supervise是开源工具集daemontools( http://cr.yp.to/daemontools.html )其中的一个工具,公司将这个工具单独从daemontools剥离,
并且根据公司的需求更改了源代码,这个工作是逢春同学负责
模块工具原理
模块的工作原理实际上很简单,supervise启动的时候fork一个子进程,子进程执行execvp系统调用,将自己替换成执行的模块,
模块变成supervise的子进程在运行,而supervise则死循环运行,并通过waitpid或者wait3系统调用选择非阻塞的方式去侦听子进程的运行情况,
当然同时也会读取pipe文件svcontrol的命令,然后根据命令去执行不同的动作,
如果子进程因某种原因导致退出,则supervise通过waitpid或者wait3获知,并继续启动模块,如果模块异常导致无法启动,则会使supervise陷入死循环,不断的启动模块
原理总结下来就是导师给新人所介绍的那样。
supervise使用的文件,以及我们可以利用的
supervise要求在当前目录下有status目录,同时status目录下面会有通过supervise启动的模块名的目录,而该目录下会有三个文件,分别为lock status svcontrol,对应的功能和我们可以从中获取的信息如下
- lock
- 作用:supervise的文件锁,通过该文件锁去控制并发,防止同一个status目录下启动多个进程，造成混乱
- 可以利用的信息:可以通过/sbin/fuser这个命令去获取lock文件的使用信息,如果fuser返回值为0,表示supervise已经启动,同时fuser返回了supervise的进程pid
- status
- 作用:这个文件是supervise用来记录一些信息之用,可以简单的理解为 char status[20],其中status[16]记录了supervise所启动的子进程的pid，status[17]-status[19] 是子进程pid别右移8位,没搞懂为什么supervise要这么做,而status[0]-status[11] 没有用,status[12]-status[14] 是标志位,一般没啥用,status[15] 直接为0
- 可以利用的信息:可以直接通过od命令去读取该文件,一般有用的就是od -An -j16 -N2 -tu2 status可以直接拿到 supervise所负责的子进程的pid
- svcontrol
- 作用:可以理解为一个控制接口,supervise读取这个管道的信息,进而根据管道的信息去控制子进程,而通过控制子进程的方式实际上就是给子进程发信号,因此实际上跟自己通过kill命令给supervise所在的子进程发信号从功能上没有本质的区别,但是通过控制接口的方式的话,准确性会非常的高
- 可以利用的信息:直接写命令到该文件中,如echo 'd' > svcontorl, 让supervise去控制子进程,比较常用的命令如下
- d: 停掉子进程,并且不启动
- u: 相对于d,启动子进程
- k: 发送一个kill信号，因kill之后supervise马上又重启,因此可以认为是一个重启的动作
- x: 标志supervise退出
对于以上三个文件,从中获取的信息的用处,我认为主要在优化模块的控制脚本上面,
现有的控制模块起停脚本一般都是通过grep命令去获取对应的进程的pid，然后发送信号给对应的pid，
这种方式是从外部方式获取信息,在准确性上面会差一点,可能会造成误杀,而如果通过status目录的三个文件去获取模块的信息,
并且通过svcontrol控制接口去控制,这种方式是从内部方式去获取模块运行的一些信息,能够保证准确性
space现在部分模块的起停脚本已经更改过,但是没有全面推广,因现在推广的需求不强烈,因此推广也没有排期
transmit和memcached使用supervise的问题
OP同学会发现,使用supervise去启动transmit的时候,然后通过pstree space(或者其他工作帐号)去观察进程的时候,会发现进程打印的不规范,如下
supervise.trans---supervise.trans
transmit---2*[transmit]
具体原因是这样子的,supervise通过waitpid或者wait3去侦擦子进程的情况,但是由于transmit这个模块在内部逻辑里面要求自己形成守护进程,
进而脱离了supervise这个父进程,成为init的子进程,此时waitpid或者wait3返回的不是预期的,supervise就认为子进程异常
从而进入了启动transmit的阶段,去重启启动一个transmit，但是新启动的transmit因为端口已经被占用,因此无法启动
自己进程退出,supervise又认为子进程异常,从而陷入死循环,不断的重启transmit，因此通过pstree 去看就形成那种格式
因为此时transmit和superivse.transmit已经不是父子关系了。当然需要提一下的是,supervise在死循环重启子进程的时候,
每次重启前都会sleep 一段时间,因此可以认为几乎不耗机器的资源
memcached如果使用了-d选项,也会出现如上的问题,-d选项为memcached自己形成守护进程,
因此现在space的memcached一般都把-d选项关闭,理论上只要形成守护进程的程序,使用supervise去启动的时候都会有这个问题
这个跟rd有很大的关系,个人建议rd写程序的时候不要自己去把程序写成守护进程,没啥意义