.NET 6在Linux中读取子进程标准输出阻塞问题咨询

问题原因 #

这不是.NET的bug，而是Linux与Windows进程模型及文件描述符继承规则的差异导致的：

• 在Windows中，使用UseShellExecute=true启动子进程时，子进程不会继承父进程被重定向的管道句柄，prog2退出后，prog1的stdout管道写端会被关闭，ReadToEnd()能正常完成。
• 在Linux中，UseShellExecute=true会通过系统shell启动prog3，shell会继承prog2的所有打开文件描述符（包括被prog1重定向的stdout管道写端），prog3又会继承shell的文件描述符。即使prog2退出，prog3仍在运行并持有该管道的写端，导致prog1的StandardOutput.ReadToEnd()一直阻塞——因为管道的写端未完全关闭，系统认为还有可能有数据写入。

解决方案 #

只需修改prog2启动prog3的逻辑，避免prog3继承prog2被重定向的stdout管道即可，以下是两种可行方案：

方案1：将prog3的输出重定向到终端 #

通过UseShellExecute=false显式控制prog3的标准输出，将其指向当前终端（而非继承prog2的管道）：

// prog2修改后的代码
using System.Diagnostics;

var processStartInfo = new ProcessStartInfo("prog3")
{
    UseShellExecute = false,
    // 将prog3的标准输出/错误重定向到当前进程的控制台输出
    StandardOutput = Console.OpenStandardOutput(),
    StandardError = Console.OpenStandardError()
};

using var process = Process.Start(processStartInfo);

方案2：丢弃prog3的输出（不需要查看时） #

如果不需要prog3的输出，可以将其重定向到/dev/null，同时异步读取输出避免阻塞：

// prog2修改后的代码
using System.Diagnostics;

var processStartInfo = new ProcessStartInfo("prog3")
{
    UseShellExecute = false,
    RedirectStandardOutput = true,
    RedirectStandardError = true
};

using var process = Process.Start(processStartInfo);
// 异步读取并丢弃输出，防止prog3因输出缓冲区满而阻塞
_ = process.StandardOutput.ReadToEndAsync();
_ = process.StandardError.ReadToEndAsync();

额外说明 #

不要依赖UseShellExecute=true在跨平台场景下的一致行为——它在Windows和Linux的实现逻辑差异很大。对于需要跨平台兼容的进程启动逻辑，建议优先使用UseShellExecute=false，并显式控制所有标准流的处理方式。

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