Linux C++场景下分离线程回收子进程相关技术问题咨询

问题背景 #

我方负责开发可被多团队父应用集成的子进程及配套调用API，子进程可执行文件路径为exe_path，当前供父进程调用的子进程创建代码如下：

void childReaper()
{
   wait(NULL);
}   


bool childSpawn()
{
    /* some logic here
    exe_path : path to the child process 
     */
    int child_pid = fork();
    if (child_pid < 0)
    {
        return false;
    }
    else if (child_pid ==0)
    {
        if(execv(exe_path.c_str(),args) == -1)
        {
             return false;   
        }
        exit(0);
    }
    else
    {
        std::thread tReaper(childReaper);
        tReaper.detach();
        return true;
    }
}

现存约束与现象 #

• 无法通过配置SIGCHLD或自定义信号实现子进程回收：集成方分属不同团队，无法保证信号不被占用、后续不修改信号配置，存在信号冲突风险。
• 阻塞式wait会阻塞父进程业务逻辑，不符合子进程设计初衷。
• 最初尝试的分离线程调用wait回收方案未生效，当前环境存在大量defunct（僵尸）子进程残留。

业务逻辑说明 #

父进程通过端口与子进程通信，规则如下：

• 父进程停止通信后数分钟，子进程主动退出
• 父进程存活时，子进程仅在收到父进程发送的exit消息后退出
• 父进程数分钟未收到子进程通信消息，会重新创建新的子进程
• 父进程存在挂起后重启的场景，是僵尸进程高发的核心诱因

核心疑问解答 #

1. 分离线程是否可以完成子进程回收 #

分离线程本身具备执行wait回收子进程的能力，当前方案失效是代码逻辑存在缺陷导致的：

• 代码中使用无参数的wait(NULL)会无差别回收调用进程下任意一个已退出的子进程，而非绑定当前创建的目标子进程。多次调用childSpawn生成多个子进程、或父进程自身创建了其他子进程时，分离线程的wait可能抢到其他子进程的回收事件，目标子进程的退出事件可能被其他逻辑的wait取走，最终导致部分子进程无人回收变为僵尸。
• 存在竞态风险：如果子进程在分离线程完成启动前就退出，或父进程提前将SIGCHLD设置为SIG_IGN触发内核自动回收，分离线程的wait会直接返回错误，无法完成预期回收逻辑。
  若要修复分离线程方案，需要给childReaper传入当前创建的child_pid，在线程内调用waitpid(child_pid, NULL, 0)精准回收对应PID的子进程，替换无差别的wait(NULL)。

2. 父进程挂起/重启场景下的子进程收养与退出行为 #

需要分两种场景讨论：

• 若父进程只是被信号挂起（如收到SIGSTOP进入TASK_STOPPED状态）、未实际退出：子进程的父进程ID不会改变，不会被init进程收养。子进程退出后会一直保持僵尸状态，直到父进程恢复运行执行wait，或父进程彻底退出。
• 若父进程彻底退出后重启：旧父进程创建的所有存活子进程会立刻被PID为1的init进程（现代Linux发行版通常为systemd）收养。这部分子进程后续退出时，init进程会自动执行wait完成回收，不会残留为僵尸。
  如果父进程反复出现「挂起-恢复-创建新子进程-不执行wait」的行为，挂起期间退出的子进程会持续作为僵尸占用进程表项，长期累积会耗尽进程号配额，导致父进程无法创建新进程，直到父进程退出后这些僵尸才会被init回收。

3. 父进程挂起恢复后执行wait的影响 #

如果父进程确实对所有创建的子进程执行了wait，挂起恢复操作不会造成永久性资源泄漏：

• 父进程挂起期间子进程退出的话，内核会将子进程的退出状态暂存在进程表中，不会丢失，仅会暂时以僵尸形式存在。
• 父进程恢复运行后，wait调用会正常读取暂存的退出状态，完成资源回收，僵尸进程占用的进程号、内核内存会立刻释放。
• 唯一的短期影响是父进程挂起期间，大量僵尸子进程会占用少量内核内存与进程号，若挂起时间极长、期间创建退出的子进程量级极大，可能短暂触发进程号不足的问题，父进程恢复完成回收后即可恢复正常。

4. 无父进程控制权场景下的可靠回收方案 #

存在完全不依赖父进程信号配置、不阻塞父进程、不受父进程行为影响的方案，核心思路是通过双fork让实际执行业务的子进程直接被init收养，所有逻辑封装在childSpawn函数内部，父应用无感知不需要做任何配合，具体实现逻辑：

1. 第一次fork出临时子进程后，父进程侧立刻调用waitpid回收这个临时子进程，该调用只会等待临时子进程退出，几乎不会产生阻塞。
2. 临时子进程内立刻执行第二次fork，生成实际运行业务逻辑的工作子进程，fork成功后临时子进程立刻调用_exit(0)退出。
3. 临时子进程退出后，工作子进程会立刻被init进程收养，后续工作子进程退出时init会自动完成回收，完全不需要父进程执行任何wait操作，也不受父进程信号配置、挂起/重启行为的影响。
4. 额外在工作子进程内调用setsid()脱离原进程组、会话，避免父进程退出时的信号广播干扰工作子进程正常运行。
   该方案可靠性远高于分离线程回收方案，是这类无法控制父进程行为场景下的标准实现。

内容的提问来源于stack exchange，提问作者Shreyak Mysore Shamprasad