C语言程序中获取exec()、system()启动进程PID的实现方法

• 首先明确exec系列函数的核心行为：它不会创建新的内核进程，只会把当前调用exec的进程的地址空间（代码、数据、堆栈）替换为目标可执行文件的内容，整个过程中进程的PID、进程组ID等内核标识完全保持不变。
• 对应给出的示例代码，fork()成功执行后，父进程分支里返回的pid变量值，就是后续执行execlp("ls", "-a", NULL)的进程的PID——从fork成功的那一刻起，这个PID就已经确定了，根本不需要额外的进程探测操作。
• 常见的认知误区是以为执行exec后会生成新的PID，实际上完全不会：子进程从fork创建出来开始，它的PID就固定了，不管后续替换成什么可执行文件，PID都不会变。
• 针对“仅需获取PID读取运行统计、无需终止进程”的需求，完全可以在拿到这个pid值之后，直接读取/proc/[pid]/stat这类文件获取运行统计，不需要等wait(0)阻塞、也不需要等进程执行完成。示例代码里的wait(0)只是父进程用来回收退出的子进程资源、避免产生僵尸进程的操作，和PID获取没有任何关系。
• 小提示：示例代码里的execlp调用参数写法存在小问题（第二个参数对应目标进程的argv[0]，规范写法应该是execlp("ls", "ls", "-a", NULL);），但这个问题完全不影响PID的获取逻辑。

• system()是glibc封装的标准库接口，它的内部实现是固定的：在内部代码里完成fork、在子进程里调用shell执行目标命令、在父进程里阻塞等待目标命令执行完成、最后把命令的退出状态码作为返回值返回给调用方。
• 最容易踩的坑是：system()的返回值是目标命令的退出状态码，不是子进程的PID。而且因为fork的操作是在glibc的内部代码里完成的，主程序根本拿不到它内部生成的子进程的PID。
• 更关键的是，system()默认是阻塞逻辑：等目标命令完全执行完成、子进程被回收之后，system()才会返回到用户编写的代码里——这时候目标进程早就退出了，对应的PID已经被内核回收，根本没法在system()调用前后拿到运行中进程的PID去读统计信息。
• 如果非要在使用system()启动流程的场景下抓PID，没有可靠的原生方法，只能靠额外的兜底手段：
  • 遍历/proc目录下的所有进程，通过匹配命令行参数、父子进程关系定位目标进程，但这种方法存在严重的竞态和误匹配问题，很容易抓到其他同名进程，也很难在短生命周期的进程退出前完成PID抓取。
  • 本质上如果要稳定拿到PID，最终还是要回到自己实现fork+exec的流程，把fork返回的PID直接留存下来——这种方式下其实就脱离了封装好的system()接口的能力范围。

• 所有需要获取启动进程PID的场景，最可靠、最无竞态的方案，都是在fork创建子进程的阶段直接留存返回的PID值，完全不需要等后续exec执行、也不需要做进程终止操作，拿到PID就可以直接去读取对应的运行统计信息。
• 只要后续等进程退出后主动调用wait系列接口回收资源，就不会产生僵尸进程，整个流程完全符合“仅读统计、不强制终止进程”的需求。

内容的提问来源于stack exchange，提问作者JavaDumbell