php-fpm重启导致程序执行中断的详细说明

背景和初步调查

订单业务对账时出现报警。有一个订单在我们自己的mongo数据库中找不到业务接口。/3/xx/vgift/send调用礼品系统的sendPresent接口完成礼品，然后写了mongo。但是，在php错误日志中没有发现mongo异常日志，但是它没有记录在数据库中。由此推断，只有两种可能：1。错误日志丢失了日志；2.程序在发送礼物后关闭，导致没有写mongo-。——第一种情况，经过多年工作经验，应该不是，那就按照第二种情况继续查。

然后查看php-fpm的日志，看对应时间点有无异常[[email protected]~]$ grep ' 201705336028 '/var/log/PHP-fpm . log[25-jun-201705336028:01]通知：终端

熟悉php-fpm的管理

Php-fpm由命令php-fpm管理。让我们先看看这个命令

Man php-fpm这里提到php-fpm然后对严重POSIX信号的响应PHP-fpm将处理以下信号(自身)

Sigint，sigterm :立即终止sigquit :正常停止sigusr 1:重新打开日志文件sigusr 2:正常重新加载所有工作人员重新加载fpmconf/二进制

sudo kill -QUIT {php-fpm-pid}

[2017年6月26日13:58:22]完成通知：[26-2017年6月13:58:22]通知：退出，再见！sudo kill -TERM {php-fpm-pid}

[2017年6月26日13:59:21]通知：终止.[26-2017年6月13:59:21]通知：退出，再见！sudo kill -USR2 12583

[2017年6月26日14:00:48]正在重新加载.[26-Jun-2017 14:00:48]NOTICE :重新加载： execvp('/usr/sbin/php-fpm '，{'/usr/sbin/php-fpm '，'-daemonize ' })[26-Jun-2017 14:0003:48]NOTICE 3360使用继承的套接字fd=8，' 10.

05:28:01有人给php-fpm发了SIGTERM信号。此时发生这种情况可能是一个定时任务，并且已经确认它是28 5 * * * root/etc/init.d/PHP-FPM重启/dev/null

我们的php-fpm管理

Init脚本是/etc/init.d/php-fpm，其中stop是killproc -p ${pidfile} php-fpm。显然，日志结果是kill -TERM。该文档还表示，默认信号是术语kill proc，它向所有使用指定可执行文件的进程发送信号。如果未指定信号名称，则发送信号符号。看看nginx在这种情况下的反应

总结原因

在业务请求中执行了sendPresent的操作之后，php-fpm在编写mongo库之前就被终止了，mongo库正好赶上了替代方案

虽然php-fpm没有解释终止和优美停止的具体含义，但是猜测前者直接终止程序的执行，后者可能比较温和，杀死正在处理的请求中的所有操作。总之，SIGTERM终止太粗糙，无法调整php，不如改成SIGUSER2重载模式和SIGQUIT模式。将短语killproc -p ${pidfile} php-fpm改为killproc-p $ { pidfile } php-fpm-退出PHP-FPM的工作人员将在计数n次后杀死并拉出另一个。如果通过重新加载重复该功能，则无需定期重启。我最好选择优雅的停止(SIGQUIT)。当然，当出现问题时，为什么要配置定期重启？将以上内容发送给sa，并与sa一起阅读问答

南非提出了三点意见

看-QUIT时Nginx的状态码正常吗？另外，在某些情况下，可能会导致PHP-FPM进程长时间退出，影响部署？使用reload(SIGUSER2)而不是SIGTERM来停止和重新启动。在我们之前的测试结果显示reload之后，nginx将报告502，这不是一个优雅的停止。建议进行测试确认，包括部署php代码时是否重新加载。Bug # 60961优雅重启(usr2)不是很优雅的PHP——FPM每天都会定期重启脚本。这个楷书大概是2012年部署的，当时因为怕PHP-FPM内存泄露才加进去的。现在还适用吗？建议找台机器关掉计时脚本，观察很久。我回答

不清楚SIGQUIT是否正常，但默认SIGTERM立即停止php进程肯定是不正常的——根据nginx错误日志，nginx与php-fpm之间的连接已经建立，错误为“104:连接被对等方重置”；准备连接的是“111:连接被拒绝”；“111:连接被拒绝”可以接受，无法连接，用户可以稍后再试；“104:对等方重置的连接”很难接受。这个错误我理解是指连接已经建立，php突然终止，然后发送一个RST分段给nginx；背后意味着当前的请求可能只执行了一半的动作，还有动作没有完成，可能会造成数据丢失。比如文章开头的reload问题实际上是-USR2信号，这个bug似乎还没有解决。然而，-USR2应该说是一个偶然的终止，但是-TERM必须是一个不可避免的终止。现在代码部署逻辑是同步代码来清理opcache和yac缓存，而不是操作php-fpm进程。php-fpm会统计工作进程本身处理的请求数量，当达到一定数量时，将其杀死，再次拉取；因此，工作进程应该没有内存泄漏问题；经理流程不清楚，但我认为概率应该极低。很难伪造这种感觉。那么为什么不找三台机器，一台有-QUIT，一台有-USR2，一台没有这个预定任务；先观察sa回复就可以了，我们可以自行决定完成

SIGQUIT信号nginx中仍有104:对等方重置的连接。看来手册中的SIGQUIT:优美停止并不能保证一个请求中的所有动作都会被执行。

最终的结果是摆脱了定期重启php-fpm的任务。已经3个多月了，没有发现问题，哦耶~

参考文件

PHP-fpm信号处理程序概要PHP-fpm初始化脚本killproc手册页

以上就是本文的全部内容。希望本文的内容对大家的学习或工作有一定的参考价值。谢谢你的支持。