[Process]: Start detached process

[adamsitnik]

Background and motivation

There is currently no easy, cross-platform way to start a detached process in .NET. A detached process is one that:

• Does not belong to the parent process's process group
• Continues running after the parent process exits
• Has its standard input/output/error disconnected from the parent

This is a common requirement for scenarios such as:

• Starting long-running server applications or daemons
• Launching GUI applications from console tools
• Creating background services that outlive the parent process

Currently, achieving this requires platform-specific workarounds like invoking shell commands like nohup <command> & through /bin/sh, which requires concatenating arguments as strings and loses the ability to obtain the child process ID (see #104210)

These workarounds are error-prone, not portable, and don't provide consistent behavior across platforms.

API Proposal

The proposal introduces a new SafeProcessHandle method for starting and managing detached processes in a platform-agnostic manner.

namespace Microsoft.Win32.SafeHandles;

public partial class SafeProcessHandle
{
    public static SafeProcessHandle Start(ProcessStartOptions options, SafeFileHandle? input, SafeFileHandle? output, SafeFileHandle? error);
    public static SafeProcessHandle StartSuspended(ProcessStartOptions options, SafeFileHandle? input, SafeFileHandle? output, SafeFileHandle? error);

    // Starts a new detached process with standard input, output, and error redirected to NUL.
    // On Windows, the process is started with DETACHED_PROCESS and CREATE_NEW_PROCESS_GROUP flags.
    // On macOS, the process is started with POSIX_SPAWN_SETSID.
    // On other Unix systems, the process calls setsid() after fork and before exec.
+   public static SafeProcessHandle StartDetached(ProcessStartOptions options);
}

Usage Example

The following example demonstrates how to start a detached process:

using Microsoft.Win32.SafeHandles;
using System.Diagnostics;

ProcessStartOptions options = new("myserver") { Arguments = { "--port", "8080" } };

// Start a detached server process
SafeProcessHandle handle = SafeProcessHandle.StartDetached(options);

Risks

Starting a detached process is advanced scenario, when used incorrectly, it can lead to issues such as orphaned processes that continue running indefinitely.

[adamsitnik]

cc @davidfowl

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[jkotas]

Should StartSuspended, StartDetached, ... really be separate methods? It feels like these should be properties in ProcessStartOptions, so you can e.g. start a process that is both suspended and detached.

[adamsitnik]

Should StartSuspended, StartDetached, ... really be separate methods? It feels like these should be properties in ProcessStartOptions, so you can e.g. start a process that is both suspended and detached.

Great question!

This was my initial design, but when I started providing the high-level helpers for most common-scenarios (#123959), I realized that each of these helpers would need to check if the option bag does not request a Suspended process and just throw in such case.

ProcessStartOptions info = new("dotnet")
{
    Arguments = { "restore" }
};

ProcessOutput processOutput = ChildProcess.CaptureOutput(info);

Moreover, exposing these APIs as part of the option bag would "pollute" the API surface for the 99% of users who don't need to support these two niche (but valid and IMO important) scenarios.

[jkotas]

Moreover, exposing these APIs as part of the option bag would "pollute" the API surface for the 99% of users who don't need to support these two niche (but valid and IMO important) scenarios.

ProcessStartOptions has other very niche features like InheritedHandles that 99% of users won't ever use. I think we struggling with deciding whether ProcessStartOptions should or should not have the niche features. It is a mix right now that leads to poor overall design.

[adamsitnik]

Moreover, exposing these APIs as part of the option bag would "pollute" the API surface for the 99% of users who don't need to support these two niche (but valid and IMO important) scenarios.

ProcessStartOptions has other very niche features like InheritedHandles that 99% of users won't ever use. I think we struggling with deciding whether ProcessStartOptions should or should not have the niche features. It is a mix right now that leads to poor overall design.

I agree InheritedHandles are niche, but I can see some valid scenarios where they would be useful in high level helpers.

FWIW I've mentioned this in the API proposal: #123380

[jkotas]

I agree InheritedHandles are niche, but I can see some valid scenarios where they would be useful in high level helpers.

Right, you can always find a case where somebody might want to use a niche feature together with high level helpers.

[adamsitnik]

I agree InheritedHandles are niche, but I can see some valid scenarios where they would be useful in high level helpers.

Right, you can always find a case where somebody might want to use a niche feature together with high level helpers.

I was not sure myself, that is why I've mentioned this in the API proposal. I was hoping that we discuss it during the API review. Should I discuss it with API review board again? For example along with the current issue (StartDetached)?

[stephentoub]

In general, the goal of API review isn't to question fundamental assertions about a feature being needed (though we often end up discussing that); rather, it's assumed that the area owners are asserting that such functionality is necessary, and then the discussion is about the right way to expose it.

[jkotas]

Should I discuss it with API review board again? For example along with the current issue (StartDetached)?

I think StartSuspended should be re-reviewed together with StartDetached. StartSuspended + StartDetached is not composable pattern. I think it is flawed design. API composability is more important than whether we need to have an extra check in the implementation or whether somebody will see an extra property in IntelliSense.