.NET环境下通过PTY托管子进程时，子进程调用exec()导致父进程意外终止的问题咨询

这问题确实棘手——我之前在处理.NET环境下的PTY子进程管理时也踩过类似的坑，结合你提到的框架本身能实现这一点，我们可以从几个核心方向排查和修复：

核心问题根源：.NET Runtime的共享资源冲突 #

.NET Runtime内部维护了一套信号处理机制：通过匿名管道传递信号通知，再由专门的线程处理。当你调用fork时，子进程会继承这个管道的句柄。如果子进程在exec前没有彻底清理这个管道，exec后的新进程可能会意外写入该管道，触发父进程Runtime的异常处理逻辑，最终导致父进程无征兆退出。

关键修复步骤 #

1. 彻底清理子进程继承的信号管道句柄 #

框架的SystemNative_ForkAndExecProcess之所以能正常工作，核心在于它在fork后的子进程中，关闭了继承的信号管道句柄。你需要：

• 找到.NET Runtime中存储信号管道的全局文件描述符（比如源码中的g_signalPipeFds数组，包含读端和写端两个fd）
• 在子进程中，调用close()关闭这两个fd，确保exec后的进程不再持有该管道的引用

2. 重置子进程的信号处理为默认配置 #

虽然你复制了框架的“fork前清除信号处理、fork后恢复”操作，但这里的遗漏点是：子进程在exec前必须将所有信号的处理函数重置为默认（SIG_DFL）。子进程继承了父进程的信号处理上下文，exec后的进程可能会残留这些非默认逻辑，进而干扰父进程的信号处理。

示例P/Invoke代码（子进程中执行）：

// 遍历常见信号，重置为默认处理
var signalsToReset = new[] { SIGINT, SIGTERM, SIGQUIT, SIGPIPE, SIGCHLD };
foreach (var sig in signalsToReset)
{
    signal(sig, SIG_DFL);
}

3. 全面清理非必要的文件描述符 #

除了stdin/stdout/stderr，.NET Runtime还会打开很多内部句柄（比如调试管道、GC相关文件等），这些句柄被子进程继承后，exec可能会导致父进程资源异常。你可以遍历并关闭所有未设置FD_CLOEXEC的文件描述符：

int maxFd = (int)sysconf(_SC_OPEN_MAX);
// 从3开始，0-2已经通过dup2处理为PTY slave
for (int fd = 3; fd < maxFd; fd++)
{
    int flags = fcntl(fd, F_GETFD);
    if (flags != -1 && (flags & FD_CLOEXEC) == 0)
    {
        close(fd);
    }
}

4. 用纯原生线程执行fork操作 #

.NET托管线程带有GC、异常处理等上下文，fork仅会克隆调用线程，可能残留未处理的托管资源。建议通过P/Invoke创建一个纯原生线程，在这个线程中执行fork、子进程初始化和exec操作，避免托管上下文的干扰。

验证方法 #

• 先在子进程exec前完成上述所有清理步骤，再执行exec，观察父进程是否还会退出
• 如果问题依然存在，用strace跟踪父进程的系统调用（strace -p <父进程PID>），查看父进程退出前收到的信号或异常操作，定位具体触发点

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