进程调用fork与文件描述符的共享(fork,dump)

本文详细解析Linux进程描述task_struct{}

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

背景        

       原文链接:http://blog.youkuaiyun.com/ordeder/article/details/21716639 

         Linux的进程描述task_struct{}中有一个数组专门用于记录一打开的文件,其中文件描述符作为该数组的下标,数组元素为指向所打开的文件所创建的文件表项。如下图所示,文件表项是用于描述文件当前被某个进程打开后的状态信息,包括文件状态标志,记录当前文件读取的位移量(可以通过接口lseek设置),以及文件的i节点指针(i节点描述文件的具体信息,如:创建,修改时间,文件大小,文件存储的块信息)。

       不同进程打开同一个文件后,进程表和文件表的关系如下图所示:


进程的fork与文件描述符的拷贝

进程的所打开文件和在fork后的结构图如下所示,子进程是共享父进程的文件表项;


可以通过一个测试实例来证实以上的描述:

测试源码

#include "slp.h"

int main()
{
    int fd1,fd2,fd3,nr;
    char buff[20];
    pid_t pid;
    fd1 = open("data.in",O_RDWR);
    pid = fork();
    if(pid == 0)
    {   
        nr = read(fd1,buff,10);
        buff[nr]='\0';
        printf("pid#%d content#%s#\n",getpid(),buff);
        exit(0);
    }   
    nr = read(fd1,buff,10);
    buff[nr]='\0';
    printf("pid#%d content#%s#\n",getpid(),buff);
    return 0;
}
测试用例
data.in
abcdefghijklmnopqrstuvwxyz1234567890
EOF

测试结果:
pid#20029 content#abcdefghij#
pid#20030 content#klmnopqrst#

结果分析:

进程20029对文件的读取后的当前位置应该为data.in的k字符所在的位置,进程20030是由20029进程之后开始读取的,他读取文件内容不是从a开始,而是从k开始,说明20030共享了20029的文件表。

进程dump一个文件描述符




总结

进程调用fork后,子进程和父进程的文件描述符所对应的文件表项是共享的,这意味着子进程对文件的读写直接影响父进程的文件位移量(反之同理)。

进程中调用fd2 = dump(fd1) 产生的新的fd2所指向的文件表项和fd1指向的文件表项是相同的;

进程中分别调用:fd1 = open("data.in",O_RDWR); fd2 = open("data.in",O_RDWR); 那么fd1和fd2指向的文件表项是不同的。

<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 文件可精确定位崩溃代码行
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值