背景

今天发布了一个统计功能，发现线上机器没有mongo模块，于是使用phpize编译了mongo模块，再用kill -HUP 进程号重启进程。

于是乎，以前都没有问题的操作，导致了php-fpm进程全部挂掉了。

现象

1、执行操作

执行重启操作

kill -HUP 20749

这里没有输出任何东西, 再查看，发现进程挂了

于是试着重启

[root@gameyeah_my ~]# /usr/local/php/sbin/php-fpm

ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address already in use (98)

ERROR: FPM initialization failed

发现端口已经被使用，但是明明 fast-cgi没有运行了啊。

于是netstat -nalt|grep 9000，得出一个OA进程占有，这个就很奇怪了。

暂时不明。

2、解决

把OA进程kill掉后，重启发现报错

[root@gameyeah_my ~]# /etc/init.d/php-fpm restart

Gracefully shutting down php-fpm /etc/init.d/php-fpm: line 82: kill: (20749) - No such process

.........

查看php-fpm的pid文件，还存在。 这个是异常关闭进程导致的，需要手动删除，再重启 -> OK了.

3、再次出现问题

环境一样，我再次使用kill -HUP 进程号 再次出现php-fpm master进程挂掉，但是子进程都还存在

没办法，只好pkill php-fpm再使用/usr/local/php/sbin/php-fpm重启, 好, 又正常了。

研究

参考线上朋友的说明：

用HUP信号使Nginx加载新的配置文件 当Nginx接收到HUP信号的时候，它会尝试着去解析并应用这个配置文件，如果没有问题，那么它会创建新的worker进程，并发送信号给旧的 worker进程，让其优雅的退出。接收到信号的旧的worker进程会关闭监听socket，但是还会处理当前的请求，处理完请求之后，旧的 worker进程退出。

查看使用yum安装的php-fpm的reload控制脚本

reload () {

echo -n $"Reloading $prog: "

if ! /usr/sbin/php-fpm --test ; then

RETVAL=6

echo $"not reloading due to configuration syntax error"

failure $"not reloading $prog due to configuration syntax error"

else

killproc -p ${pidfile} php-fpm -USR2

## 或者 kill -USR2 `cat $php_fpm_PID`

RETVAL=$?

fi

echo

}

发现官方是使用-USR2 平滑reload的

网上这位朋友说明如下：

当你想升级Nginx到一个新的版本，增加或减少module的时候 发送USR2信号给master进程。master进程会把自己的.pid文件重命名为.oldbin(例 如，/usr/local/nginx/logs/nginx.pid.oldbin)，然后执行新的二进制文件，从而启动一个新的master进程和新的worker进程.

为了验证-HUP与-USR2的区别，做实验(回狗窝后自己机器):

1、php.ini添加上mongo.so, 使用-HUP重启，发现master进程真挂了

只好重启

[root@gameyeah_my mongo-php-driver-legacy]# pkill php-fpm ; /usr/local/php/sbin/php-fpm

2、php.ini添加上mongo.so, 使用-USR2重启, 发现一切正常进程号更新; 使用phpinfo()查看mongo模块正常使用.

3、修改php.ini, 不添加mongo.so,使用 -HUP重启 --- master进程一样关闭了，只留下子进程

4、重置，不添加mongo.so,使用 -USR2重启 --- 一切正常

5、我重新以不修改php.ini的方式分别以-HUP/-USR2尝试重启，现象与上面一样

1) 使用kill -HUP pid ，master进程关闭，没有成功启动新的master进程

2) 使用kill -USR2 pid, 旧master进程关闭，新的master进程成功启动

6、是不是php-fpm的特有性质呢？？于是改试nginx进程

1) 使用-HUP重启, 发现修改的配置生效了，但是进程号未修改

2) 使用-USR2重启，发现新的master进程起来了，旧的master进程还存在；再使用-QUIT关闭旧进程(-WINCH一样没有见关闭)，过一段时间发现旧进程真没了.

真心查看nginx官方提供的reload方法是使用-HUP

reload() {

echo -n $"Reloading $prog: "

killproc -p ${pidfile} ${prog} -HUP

RETVAL=$?

echo

}

结论

php-fpm与nginx的使用-USR2/-HUP意义不一样！

Master进程能够接收并处理如下的信号：

TERM, INT(快速退出，当前的请求不执行完成就退出)

QUIT (优雅退出，执行完当前的请求后退出)

HUP (重新加载配置文件，用新的配置文件启动新worker进程，并优雅的关闭旧的worker进程, 用于nginx的加载新配置，不能用于php-fpm加载新配置)

USR1 (重新打开日志文件)

USR2 (平滑的升级nginx二进制文件/平滑加载php-fpm新配置)

WINCH (优雅的关闭worker进程)

于是 可以自己写php-fpm控制脚本

关闭

kill -QUIT `cat $php_fpm_PID`

平滑重载配置

kill -USR2 `cat $php_fpm_PID`

强制关闭

kill -TERM `cat $php_fpm_PID`

可以自己写nginx控制脚本

关闭

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

平滑重载配置

kill -HUP `cat /usr/local/nginx/logs/nginx.pid`

平滑升级nginx,即升级新编译的nginx

复制代码

OldPid=`cat /usr/local/nginx/logs/nginx.pid`

kill -USR2 $OldPid

kill -QUIT $OldPid

--------------------------------------------

upgrade() {

oldbinpidfile=${pidfile}.oldbin

configtest -q || return

echo -n $"Starting new master $prog: "

killproc -p ${pidfile} ${prog} -USR2

echo

for i in `/usr/bin/seq $UPGRADEWAITLOOPS`; do

/bin/usleep $SLEEPMSEC

if [ -f ${oldbinpidfile} -a -f ${pidfile} ]; then

echo -n $"Graceful shutdown of old $prog: "

killproc -p ${oldbinpidfile} ${prog} -QUIT

RETVAL=$?

echo

return

fi

done

echo $"Upgrade failed!"

RETVAL=1

}