Request: System.Diagnostics.Process support for CREATE_NEW_PROCESS_GROUP creation flag

[weshaggard]

API Proposal:

namespace System.Diagnostics
{
     public sealed class ProcessStartInfo
     {
          public bool CreateNewProcessGroup { get; set; }
     }
}

Usage:

var p = new System.Diagnostics.Process();
p.StartInfo.FileName = @"cmd";
p.StartInfo.CreateNewProcessGroup = true;
p.Start();

@PaulHigin commented on Wed Mar 22 2017

The Process class currently supports StartInfo class information but no process creation flags. We (PowerShell) need support for cross platform CREATE_NEW_PROCESS_GROUP creation flag to create processes outside the parent process group. This is supported in Windows and also Linux (via setpgid()) but needs to be done during process creation.

---

@weshaggard commented on Wed Mar 22 2017

This request is better served in the dotnet/corefx repo so moving there.

[iSazonov]

I should add that the issue blocks a development of remoting in PowerShell Core.

[karelz]

Next steps: We need formal API proposal.

@iSazonov do you plan to tackle it?

[iSazonov]

I suppose we would like to have this fix before RTM as it blocks PowerShell Core 6.0 RTM.
I'm not a full time so I can't control "API proposal". Maybe PowerShell team will take it
/cc @PaulHigin @joeyaiello

[karelz]

I am not aware of PowerShell Core 6.0 schedule. If this is critical for its success, we need PowerShell team to drive the API here ASAP. The window for .NET Core 2.0 is getting smaller, we are slowly entering the end game. We can still take high-quality contributions (incl. API additions), but .NET Core team is heavily focusing on stabilization at this moment.
@PaulHigin @joeyaiello can you please chime in o the importance and if you (PowerShell team) plan to engage on this issue?

[PaulHigin]

I'll let @joeyaiello and @SteveL-MSFT discuss PowerShell Core 6.0 schedule in detail but in the near term we are trying to align PowerShell Core 6.0-beta with .Net Core 2.0 beta.

This is a blocking issue for SSH based PowerShell remoting because it prevents Ctrl+C (PowerShell/PowerShell#2321) from working in an interactive remote session. The reason is that the SSH child process created by PowerShell handles Ctrl+C signals because it is part of PowerShell's process group. The Ctrl+C signal causes SSH to terminate the current session, instead of letting PowerShell process the signal through its remoting protocol.

This issue has been fixed for Windows platform by creating the SSH process outside of PowerShell's process group, through the CREATE_NEW_PROCESS_GROUP process creation flag. But .NET does not support process creation flags and so SSH process creation is currently done using Windows native APIs via PInvoke. But this won't work on other platforms so we are requesting that this capability be added to .Net System.Diagnostics.Process class.

As for a new API request I feel we should continue following the Windows API and create a new CreationFlags property for the System.Diagnostics.Process type, that takes an enum that includes at minimum CREATE_NEW_PROCESS_GROUP which will work over Windows and Linux platforms. For Linux platforms the setgpid() API can be used to create a new process group Id during process creation.

[karelz]

Given that this is highly specific API and given the tight timelines, I think it would be best if PowerShell uses PInvokes in 6.0 on both Windows and Linux. Once you have implementation which works for your needs, we can think about adding it into .NET Core as general API on Process.
Will that work?

[PaulHigin]

For Windows it is Ok since it is already there, but for Linux it means re-producing all of the code now in .Net for creating Linux processes just to add this one flag. It would be infinitely easier to simply update existing .Net code.

[karelz]

OK, in that case please create formal API proposal - it has to take into account future cross-platform usage of the API (flags should not be Windows-centric).

Let's see if it can get through, or not. Note: No guarantees on the result - we won't push APIs into the platform, unless we are convinced they are the right thing for the platform, in the right direction, etc. (just stating the obvious ;-))

[karelz]

cc @Priya91 @stephentoub if they have deeper insight into the involved Process APIs here.

[karelz]

Here's proposal from @PaulHigin (from dotnet/corefx#17481 dupe)

This is a request for a new CreationFlags property that is identical to creation flags in Windows native API CreateProcess(). This needs to work appropriately for Windows and Linux platforms but should work identically for the CREATE_NEW_PROCESS_GROUP flag since process groups are similar between the two platforms.

Proposed API

CreationFlags property is of type CreationFlags that is an enum of supported creation flags

public CreationFlags System.Diagnostics.Process.CreationFlags { get; set; }

[Flags]
public enum CreationFlags
{
    CREATE_NEW_CONSOLE = 0x00000010,
    **CREATE_NEW_PROCESS_GROUP = 0x00000200**,
    CREATE_BREAKAWAY_FROM_JOB = 0x010000000,
    CREATE_DEFAULT_ERROR_MODE = 0x04000000,
    ...
};
```:

[karelz]

I think that new APIs should be either designed in a cross-platform way (as I mentioned above), or exposed only for specific OS (e.g. Unix file permissions, etc.).

@PaulHigin your proposal is mix of both - it exposes Windows API shape, yet asks for cross-platform implementation. We did that in the past for APIs which existed prior to .NET Core and prior to .NET cross-platform efforts. However, it is not something we want to do for new APIs. Can you please adjust your proposal from that perspective?

[Priya91]

Currently we support only create_no_window and create_unicode_environment creation (set default) flags from windows. The Create no window is exposed as property on StartInfo.

So I guess the create_new_process_group will be added as another property to startinfo. We might not support the entire creation flags enum from win32.

[Priya91]

@PaulHigin I've updated the top comment in the issue with the information on the required API. Does this satisfy your scenario?

[PaulHigin]

I am fine making CreateNewProcessGroup a Boolean on the ProcessStartInfo class since this appears to be the pattern already started (with similar CreateNoWindow Boolean). But it doesn't seem very scalable as more process creation options are added in the future.

[karelz]

@PaulHigin what would you propose? Platform independent flags? (not seeded with Windows names)