系列文章：
一 概述
系列的上一篇文章，介绍了守护进程的一些基本概念，本篇将介绍工作经历中的一个真实应用场景，以及遇到的问题，和当时的解决方法。
二 场景
在某老东家工作期间，所在部门使用php进行业务开发，框架laravel。业务代码部署，也是包括web和脚本/任务两大体系。web服务提供接口，脚本机上的服务执行任务，包括kafka消息消费、laravel队列消息处理和定时任务执行等等。
脚本机部署形态：入职初期，消费进程包括kafka-consumer，两个laravel（异步）队列进程queue:work，按照消息处理的紧迫程度定义了时效层面的优先级（low,middle,...）。
启动方式：通过artisan方式启动进程，以独立进程形态存在于操作系统中。而启动脚本会以service的形式，部署（配置）在/etc/systemd/system下，也就是前面提到过的linux守护进程，文件名类似： /etc/systemd/system/xxx.xxx.service
artisan命令在上述守护进程的配置文件中（实际上，在最终层面是通过sh run.sh执行脚本的启动运行）。
三 案例及遇到的问题
常驻进程的生命周期如下图所示：
当我们重新发布代码时，对脚本这部分来说，部署过程就是：
1、覆盖新代码
2、终止旧的进程
3、启动新的进程
第二步的终止进程，是通过系统的kill pid命令来进行的，而这种方式相当于kill -15 pid，即通过-15信号量，通知系统要进行资源回收，并终止进程。
但实际的发布时，会出现kill 失败的情况，而jenkins中编写的命令为了应对这个问题，加上了等待90s后通过kill -9 pid强杀来终止旧进程。kill pid失败的情况这在当时导致了两个问题：
1）部署时间过长，因为很多kill pid执行失败的情况发生，所以每次都需要等待90s
2）kill -9 pid是非常危险的命令。因为来不及做资源回收，在存在父子进程时，强杀父进程导致出现孤儿进程，后续发布也存在无法发布成功的情况。
最终与其他技术同学一起解决这个问题，当时是由于laravel框架对进程、信号量管理、php版本支持上的一些问题导致的。再重写进程管理、信号量handler之后，问题得以解决。
