系列文章：

【Linux 系统】关于守护进程

一 概述

系列的上一篇文章，介绍了守护进程的一些基本概念，本篇将介绍工作经历中的一个真实应用场景，以及遇到的问题，和当时的解决方法。

二 场景

在某老东家工作期间，所在部门使用 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 之后，问题得以解决。