php进程 异常退出,记一次进程异常退出的问题排查

最新推荐文章于 2024-08-03 11:32:39 发布
最新推荐文章于 2024-08-03 11:32:39 发布
阅读量2.6k 收藏 1
点赞数
文章标签： php进程 异常退出
本文介绍了一个关于PHP多进程子进程异常退出的问题排查过程。通过内核日志定位到内存访问越界的问题，并利用coredump进一步调试，最终发现是由phpredis扩展的pconnect功能引发。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

机器搬家之后，之前一直稳定的PHP多进程程序子进程突然异常退出，但是退出的不是很频繁，查看进程日志并也没有发现有什么导致退出的，问题比较诡异。于是开启了一段问题排查之路。

首先查看内核日志，使用dmesg，拉到最后发现有一些这样的错误，看来确实是崩溃了。

[4791991.998535] php[16776]: segfault at 7f6443ee18c8 ip 00007f6443ee18c8 sp 00007fff4d4ba818 error 15 in libc-2.17.so[7f6443ee1000+2000]

[4792165.192628] php[609]: segfault at 0 ip 000000000075919d sp 00007fff0c6e0578 error 4 in php[400000+94b000]

[4792423.164949] traps: php[2337] general protection ip:75919d sp:7fff0c6e0578 error:0 in php[400000+94b000]

[4793914.900298] traps: php[589] general protection ip:7576b6 sp:7fff0c6e0460 error:0 in php[400000+94b000]

[4794155.124685] php[25418]: segfault at 35007265746c ip 000000000075919d sp 00007fff0c6e0578 error 4 in php[400000+94b000]

[4794677.119847] traps: php[2314] general protection ip:75959b sp:7fff4d4ba840 error:0 in php[400000+94b000]

[4795121.747090] php[4642]: segfault at 0 ip 000000000075919d sp 00007fff0c6e0578 error 4 in php[400000+94b000]

[4795666.787427] php[2372]: segfault at 40 ip 000000000075958c sp 00007fff0c6e0500 error 4 in php[400000+94b000]

[4796212.001686] php[6224]: segfault at 10 ip 000000000075919d sp 00007fff0c6e0578 error 4 in php[400000+94b000]

[4796224.510583] traps: php[6156] general protection ip:75919d sp:7fff0c6e0578 error:0 in php[400000+94b000]

[4796337.623455] php[562]: segfault at 247ec40 ip 000000000247ec40 sp 00007fff0c6e04d8 error 15

[4796427.436886] php[1711]: segfault at ffffffffffffffff ip 00000000007576b6 sp 00007fff0c6e0460 error 5 in php[400000+94b000]

[4796554.025960] php[6662]: segfault at 6b6f01000040 ip 000000000075958c sp 00007fff0c6e0500 error 4 in php[400000+94b000]

[4797141.552356] php[6658]: segfault at 18 ip 0000000000758daf sp 00007fff0c6e04d0 error 4 in php[400000+94b000]

[4797495.302089] php[7239]: segfault at 110 ip 00000000007576d2 sp 00007fff0c6e0460 error 4 in php[400000+94b000]

[4797867.446166] php[8265]: segfault at 247e730 ip 000000000247e730 sp 00007fff0c6e04d8 error 15

[4798245.596106] php[8223]: segfault at 247ef40 ip 000000000247ef40 sp 00007fff0c6e04d8 error 15

[4798514.326132] traps: php[8152] general protection ip:75919d sp:7fff0c6e0578 error:0 in php[400000+94b000]

[4798769.904337] traps: php[7255] general protection ip:7576d2 sp:7fff0c6e0460 error:0 in php[400000+94b000]

[4799427.934198] php[2297]: segfault at 17b57d0 ip 00000000017b57d0 sp 00007fff4d4ba838 error 15

[4800091.548467] php[9826]: segfault at 247ed10 ip 000000000247ed10 sp 00007fff0c6e04d8 error 15

[4800607.342570] php[11239]: segfault at 100000007 ip 000000000075919d sp 00007fff0c6e0578 error 4 in php[400000+94b000]

[4800806.439680] php[9796]: segfault at 247ec90 ip 000000000247ec90 sp 00007fff0c6e04d8 error 15

[4801110.909591] php[8317]: segfault at 247ed20 ip 000000000247ed20 sp 00007fff0c6e04d8 error 15

[4801417.477197] php[9326]: segfault at 0 ip 00000000007576d2 sp 00007fff0c6e0460 error 4 in php[400000+94b000]

运气不错，现在居然就有眉目了。上面的信息一般是内存访问越界导致的。现在找一条看看

php[9326]: segfault at 0 ip 00000000007576d2 sp 00007fff0c6e0460 error 4 in php[400000+94b000]

根据网上的资料，error 后面的数字是比较有用的，上面的是4，转换成二进制是100。

bit2: 值为1表示是用户态程序内存访问越界，值为0表示是内核态程序内存访问越界

bit1: 值为1表示是写操作导致内存访问越界，值为0表示是读操作导致内存访问越界

bit0: 值为1表示没有足够的权限访问非法地址的内容，值为0表示访问的非法地址根本没有对应的页面，也就是无效地址

所以含义就是用户态读取得内存地址无效。但是这个信息太笼统。于是还需要进一步调试，这个时候就要用到core dump了。

开启core dump(核心转储)

Core Dump通常是当程序崩溃的时候，操作系统记录下来当前时间程序的内存状态信息。其中还包括处理器寄存器，程序计数器和堆栈指针，存储器管理信息以及其他处理器和操作系统标志和信息。核心转储通常用于帮助诊断和调试计算机程序中的错误。

使用ulimit -c unlimited开启core dump。由于php的核心转储文件比较大，因此建议不要限制core文件的大小，当调试完毕之后关闭coredump之后就好了。

经过一段时间的运行之后，core文件终于生成了。

可以使用下面的命令调试之前生成的core。假设我们已经进入了core文件的目录下面，php安装在/usr/local/php/下面，core文件问core.30983

gdb /usr/local/php/bin/php -c core.30983

之后我们可以看到这么一些信息(关于gdb的使用，可以自行google)

Program terminated with signal 11, Segmentation fault.

#0 0x000000000075958c in _php_stream_set_option ()

Missing separate debuginfos, use: debuginfo-install php55-5.5.6-2.el7.centos.x86_64

(gdb) bt

#0 0x000000000075958c in _php_stream_set_option ()

#1 0x0000000000759648 in _php_stream_eof ()

#2 0x00007fd73cc1f014 in redis_check_eof (redis_sock=redis_sock@entry=0x2847918, no_throw=no_throw@entry=0) at /tmp/pear/temp/redis/library.c:167

#3 0x00007fd73cc1ef8f in redis_sock_write (redis_sock=redis_sock@entry=0x2847918,

cmd=0x281b038 "*4\r\n$5\r\nSETEX\r\n$48\r\nlock::createid::b476a966712ffc251747356512675590\r\n$2\r\n10\r\n$1\r\n1\r\n", sz=85)

at /tmp/pear/temp/redis/library.c:1926

#4 0x00007fd73cbf6113 in zim_Redis_setex (ht=3, return_value=0x28af538, return_value_ptr=0x0, this_ptr=0x2820640, return_value_used=1)

at /tmp/pear/temp/redis/redis.c:875

#5 0x000000000084e9c8 in zend_do_fcall_common_helper_SPEC ()

#6 0x00000000007c88d8 in execute_ex ()

#7 0x00000000007a1130 in zend_execute_scripts ()

#8 0x0000000000742bfb in php_execute_script ()

#9 0x0000000000850751 in do_cli ()

#10 0x0000000000432c7f in main ()

可以看到引起segfault的原因是phpredis的扩展的问题。目前还没有深入php的源代码，不清楚到底是什么导致读取了非法的内存地址，因此只能去搜索这个错误了。在phpredis的github中的issue中看到有很多人遇到了和我一样的问题，原因是pconnect导致的。在常驻内存的脚本中，使用pconnect可能会引起上面的问题。

最终把pconnect改成connect就没问题了。

赞赏

记一次supervisor启动子进程失败
zhuangzi123456的博客
02-19 2212
现象： [root@wangzhandaima supervisor]# supervisorctl update consumer_for_unpaid_order_status_check: added process group [root@wangzhandaima supervisor]# supervisorctl status admin_info RUNNING pid 2...
记一次centos系统下的串口登陆异常问题
westlor的专栏
11-16 1925
在使用centos7.5版本系统时，安装配置好桌面环境后，发现通过串口登陆系统出现了问题。 https://www.centos.org/forums/viewtopic.php?t=61569 https://bugzilla.redhat.com/show_bug.cgi?id=691374 ...
php主进程退出,如何防止PHP进程异常退出（进程被杀）？
weixin_39963830的博客
03-11 307
背景通常，在cli下运行的常驻后台PHP进程，可能异常退出，比如php执行过程中出现的致命错误，或被 kill 命令手动杀死等。如下面的php代码：while(1){$content = fgets(STDIN);if(empty($content)){sleep(1);}//逻辑处理部分代码省略}排查过程我们使用register_shutdown_function来跟踪下到底是什么错误导致的进程...
一次php进程诡异退出的排查过程
zhangwuhaoda的专栏
01-26 1051
背景 最近给XX项目搭建一个反垃圾平台。效果不错，但是出现了一个诡异的事情。离线扫描部分会有一个常驻的php进程，以便处理发现的垃圾信息。常驻的php进程总是诡异的退出。php代码示例如下： <?php while(1){ $content = fgets(STDIN); if(empty($content)){ sleep(1); } //逻辑处理部分代码省略 }
php 守护进程报错导致,php中两种守护进程的方式
weixin_35711852的博客
03-11 316
本篇文章主要介绍php中两种守护进程的方式，感兴趣的小伙伴参考下，希望可以帮助到大家。第一种方式，借助 nohup 和 & 配合使用。在命令后面加上 & 符号， 可以让启动的进程转到后台运行，而不占用控制台，控制台还可以再运行其他命令，这里我使用一个while死循环来做演示，代码如下while(true){echo time().PHP_EOL;sleep(3);}用 &...
segfault at php,segfault at错误日志
weixin_35785793的博客
04-11 299
早些天查看nginx的日志发现有这样的错误：奇怪了这是php-cgi不够用啊！！！！实际上我开启的php-cgi的数目远大于实际使用的数目。查看php的日志查看到当时有大量的php-cgi进程重启(按照php-cgi的102400和当时的访问量不应该有这么多的php-cgi重启)。查看系统日志：大量的这样的记录日志，而且时间和nginx错误日志中记录的时间一样。难道是redis出什么问题了，查看r...
segfault at php,nginx php-fpm安装后的问题
weixin_26850469的博客
04-11 439
nginx+fastcgi问题及解决办法1、内核错误Mar 11 10:31:52 web2 kernel: [1117529.269606] php-cgi[13361]:segfault at 18 ip 71add2 sp 7fff874aafc0 error 4 inphp-cgi[400000+695000]Mar 11 10:32:08 web2 kernel: [1117594.78...
php5.2的curl-bug 服务器被php进程卡死问题排查
10-21
本文将重点介绍PHP 5.2版本中一个特定的curl-bug引发的服务器被PHP进程卡死问题排查。这一问题最初是由东政同学在Linode服务器上发现的，表现在系统负载极高，大量PHP进程占用CPU资源无法正常退出，导致服务器运行...
linux进程监控shell脚本代码
09-15
当检测到PHP进程异常退出时，脚本会使用`$PHP`变量指定的PHP执行路径再次启动进程。例如：`$PHP /home/httpd/$PROGRAM >>/usr/local/scripts/phpshell/receve.out &`。这个命令不仅执行了PHP脚本，还将标准输出...
Linxu系统服务管理，systemd知识/进程优先级/平均负载/php进程CPU100%怎么解决系列知识！
2302_78067597的博客
04-28 1221
进程执行时候是排队执行的，需要插队，要调整。进程重要性高，需要优先多分配CPU。调整优先级。#记住用途nice： 调整【程序运行时】的优先级 renice：调整【运行中的进程】的优先级区别:nice命令常用于修改未运行的程序再运行时的优先级，但是对于正在运行的进程，若想要修改优先级，就需要用到renice命令。衡量系统繁忙的一个综合性指标，主要是cpu/io的繁忙程度；在工作中非常常用。工作中非常的常用，具体是哪一个指标繁忙ps，top，sar看cpu。
linux php 进程初探（四）进程退出
专注于php高级知识分享
01-27 2042
linux php 进程初探（四）进程退出 #基本概念 一个程序启动之后，会变成一个进程，进程在什么情况下会退出呢？ 以下情况下进程会退出： 运行到最后一行语句 运行时遇到return时 运行时遇到exit()函数的时候 程序异常的时候 进程接收到中断信号 在c/c++中还有更多进程退出的情况，本文暂且不表，我们这里只关注php中进程退出的情况 一个进程要么是正常结束，要么是异常结束（异常结束大多跟信号有关），不管是何种方式导致进程退出，它都有一个终止状态码，进程结束时并不会真的退出，还会驻留
如何监测PHP进程异常退出（进程被杀）的原因？
arthasking123的博客
06-30 1206
背景 通常，在cli下运行的常驻后台PHP进程，可能异常退出，比如php执行过程中出现的致命错误，或被 kill 命令手动杀死等。如下面的php代码： 1 2 3 4 5 6 7 8 9 <?php while(1){ $content=fgets(STDIN); if(empty($content)){ sleep(1); ...
segfault at错误日志
weixin_34228617的博客
11-02 2475
早些天查看nginx的日志发现有这样的错误：奇怪了这是php-cgi不够用啊！！！！实际上我开启的php-cgi的数目远大于实际使用的数目。查看php的日志查看到当时有大量的php-cgi进程重启（按照php-cgi的<value name="max_requests">102400</value>和当时的访问量不应该有这么多的php-cgi重启）。...
防止 php 进程关闭,关于PHP进程防止内存溢出的排查_后端开发
weixin_35377249的博客
04-13 213
php如何使用PHPAnalysis提取关键字中文分词_后端开发需求：做SEO的keywords时，需要从标题或者正文里提取关键字，下载后解压放到extend目录下(以tp5为例，其他目录也行)。PHP进程内存大小是可以设置的，默认在配置文件 memory_limit=128M也可以在程序中动态设置 ini_set('memory_limit', '1024M');这样就设置成1G了。但是一般不会...
如何在没有core文件的情况下用dmesg+addr2line定位段错误
jinking01的专栏
08-25 1301
段错误的调试定位方法
【linux】【操作系统】内核之traps.c源码阅读
weixin_42105599的博客
08-03 988
C 文件·traps.c是 Linux 内核的一部分，主要处理硬件陷阱和故障。文件中包含多个函数来处理不同类型的异常和错误。
php项目重启,【PHP-FPM】重启过程源码详解
weixin_36309193的博客
03-09 985
一、概要在工作中，我们经常需要重启PHP-FPM，那么这个重启过程都发生了那些事情呢？让我们从PHP源码中一探究竟吧。运行环境： Mac 10.14.2 + PHP 7.3.7二、源码解析信号在fpm的重启中扮演着重要的角色。那什么是信号呢？信号是由用户、系统或者进程发送给目标进程的信息，以通知目标进程某个状态的改变或系统异常。Linux信号可由如下条件产生：对于前台进程，用户可以通过输入特殊的终...
Linux进程崩溃原调试
guotianqing的博客
09-04 2892
简介 每个开发服务主程的同学可能都有进程崩溃的经历，这时候就要了解点Linux下进程调试方法了。 以下信息都有助于调试： 良好的程序编码，有日志记录 崩溃时产生了core文件 通过dmesg查看内核日志信息 调试进程崩溃的方法有很多，可以根据具体需求使用。 调试 一般的调试流程，先从容易获取的信息入手，直到找到原因为止。 进程日志 在程序开发中，肯定会记录一些日志，而日志记录的好坏可以直接影响调试，进而影响程序的发布进程。 目前有很多的开源日志库，选择合适的即可。如log4cplus等。 日志
如何通过 `strace` 诊断 PHP-FPM 进程崩溃的具体原因？
最新发布
06-18
<think>我们正在诊断PHP-FPM进程崩溃的问题，并计划使用strace工具来追踪系统调用。根据引用[1]，高并发时可能出现502错误，可能与PHP-FPM处理请求队列有关。引用[2]提到了使用Unixsocket（放在/dev/shm内存设备）来提升性能。引用[3]则提供了一个在Docker中运行Nginx和PHP-FPM并模拟高并发的测试命令。使用strace诊断PHP-FPM进程崩溃的步骤：1.**确定目标进程**：首先需要找到要跟踪的PHP-FPM进程。由于PHP-FPM是多进程模型，我们需要选择一个经常崩溃的进程进行跟踪。可以通过查看日志或监控进程状态来找到崩溃的进程ID（PID）。2.**使用strace附加到进程**：一旦确定目标PID（假设为12345），使用以下命令附加：```bashstrace-p12345-f-s2048-o/tmp/php-fpm-strace.log```参数说明：-`-p12345`：指定要跟踪的进程ID-`-f`：同时跟踪由该进程创建的子进程（fork）-`-s2048`：设置字符串的最大显示长度（避免被截断）-`-o`：将输出保存到指定文件3.**重现问题**：在strace运行期间，模拟请求（如使用ab工具，如引用[3]所示）来触发崩溃。观察strace的输出直到进程崩溃。4.**分析日志**：进程崩溃后，检查strace日志文件（/tmp/php-fpm-strace.log）。重点查找以下内容：-崩溃前的最后几个系统调用-信号（如SIGSEGV、SIGABRT等）的接收-资源相关的错误（如ENOMEM内存不足，EAGAIN资源暂时不可用）-文件描述符操作异常5.**常见崩溃原因分析**：-**段错误（SIGSEGV）**：通常由非法内存访问引起，可能是PHP扩展或PHP代码本身的问题。-**内存不足（OOM）**：系统调用中出现`brk`或`mmap`失败，并伴随`ENOMEM`错误。-**超时或资源不足**：如`poll`、`epoll_wait`等系统调用长时间阻塞，然后被信号中断。6.**结合其他日志**：同时查看PHP-FPM的错误日志（如`/var/log/php-fpm/error.log`）和系统日志（`dmesg`或`/var/log/messages`），寻找与strace日志中异常对应的记录。7.**针对多进程的跟踪**：如果无法确定具体哪个进程会崩溃，可以同时跟踪所有PHP-FPM进程：```bashpgrepphp-fpm|xargs-n1strace-f-s2048-o/tmp/php-fpm-strace-pid_{}.log-p```这会将每个进程的strace输出保存到单独的文件。8.**分析示例**：在strace日志中，如果看到类似以下内容，表明进程因段错误而退出：```---SIGSEGV{si_signo=SIGSEGV,si_code=SEGV_MAPERR,si_addr=0x7f8e2b2b6000}---+++killedbySIGSEGV+++```或者内存不足：```mmap(NULL,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0)=-1ENOMEM(Cannotallocatememory)```9.**优化建议**：-根据引用[2]，使用Unixsocket并放在内存文件系统中（如/dev/shm）可以减少网络开销，提高稳定性。-调整PHP-FPM配置（如`pm.max_children`）避免资源耗尽。-检查PHP扩展：通过禁用可疑扩展来排查。10.**生成核心转储**：如果strace不能提供足够信息，可以配置系统生成核心转储（coredump），然后用gdb分析。注意：在高负载环境下，strace可能会显著降低性能，因此建议在测试环境中重现问题。通过以上步骤，我们可以定位PHP-FPM进程崩溃的具体原因。§§相关问题§§1.如何配置PHP-FPM生成核心转储（coredump）以分析段错误？2.如何优化PHP-FPM的进程管理设置（pm）以避免崩溃？3.在Docker容器中如何诊断PHP-FPM进程崩溃？</think>### 使用 `strace` 诊断 PHP-FPM 进程崩溃的完整指南 #### **核心诊断流程** ```mermaid graph TD A[定位崩溃进程] --> B[实时跟踪系统调用] B --> C[触发崩溃场景] C --> D[分析关键错误信号] D --> E[定位问题根源] ``` #### **步骤 1：定位目标进程** ```bash # 获取 PHP-FPM 主进程 ID pgrep php-fpm # 查看子进程列表（选择常崩溃的 Worker 进程） ps -efL | grep php-fpm | grep -v master ``` > 选择频繁重启的 Worker 进程 ID（如 PID 12345）作为跟踪对象[^1] #### **步骤 2：实时跟踪系统调用** ```bash # 附加到目标进程进行跟踪 strace -p 12345 -f -s 2048 -o /tmp/php-fpm-strace.log # 关键参数说明： # -p : 指定进程ID # -f : 跟踪子进程（Fork 创建的 Worker） # -s 2048 : 显示完整字符串（避免截断错误信息） # -o : 保存日志到文件 ``` #### **步骤 3：触发崩溃场景** ```bash # 模拟高并发请求（参考引用[3]） ab -c 100 -n 1000 http://your-site.com/test.php ``` > 保持 `strace` 运行直到进程崩溃，观察日志中新出现的错误[^3] --- #### **关键日志分析要点** 在 `/tmp/php-fpm-strace.log` 中排查以下关键信号： | **错误类型** | **日志特征** | **解决方案** | |--------------------|---------------------------------------------|------------------------------| | **段错误 (SIGSEGV)** | `--- SIGSEGV {si_signo=SIGSEGV, ...} ---` | 检查 PHP 扩展/内存越界[^1] | | **内存耗尽** | `mmap(..., ENOMEM)` 或 `brk()` 失败 | 增加 `memory_limit` | | **文件描述符耗尽** | `socket(... EMFILE)` 或 `accept(...)` 失败 | 调整 `ulimit -n` | | **死锁阻塞** | 长时间卡在 `futex()` 或 `poll()` 调用 | 优化数据库查询/锁机制 | | **超时中断** | `--- SIGALRM {si_signo=SIGALRM, ...} ---` | 延长 `request_terminate_timeout` | --- #### **典型案例解析** **场景：PHP 扩展导致的段错误** ```log [pid 12345] open("/usr/lib/php/20190902/redis.so", O_RDONLY) = 3 [pid 12345] read(3, "\177ELF...", 832) = 832 ... [pid 12345] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7f8a} --- ``` > **诊断**：Redis 扩展加载后立即崩溃 → 需降级扩展版本或更新 PHP 兼容版本[^1] **场景：内存泄漏** ```log [pid 12345] brk(0x1f48000) = 0x1f48000 [pid 12345] brk(0x1f89000) = 0x1f89000 # 频繁调用brk ... [pid 12345] mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM ``` > **诊断**：进程持续申请堆内存 → 使用 `valgrind` 检查 PHP 脚本内存泄漏 --- #### **优化建议** 1. **优先使用 Unix Socket**（引用[2]） ```nginx fastcgi_pass unix:/dev/shm/phpfpm.sock; ``` ```ini ; php-fpm.conf listen = /dev/shm/phpfpm.sock ``` 2. **启用 PHP-FPM Slow Log** ```ini ; 记录执行超过 5 秒的脚本 request_slowlog_timeout = 5s slowlog = /var/log/php-fpm/slow.log ``` 3. **崩溃后自动生成 Core Dump** ```bash # 在 /etc/systemd/system/php-fpm.service.d/core.conf 添加： [Service] LimitCORE=infinity Environment=PHP_FASTCGI_CORE_DUMP=1 ``` > 提示：结合 `gdb` 分析 core dump 文件可精确定位崩溃代码行
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值