Runtime: System.Diagnostics.Process.ProcessName returning incorrect information on Linux with .NET 5

[SteveL-MSFT]

Moving PowerShell to .NET 5 via branch https://github.com/SteveL-MSFT/PowerShell/tree/dotnet-5

We have tests that expect the pwsh process to have a ProcessName of pwsh, but on Linux, the name is actually ConsoleHost mai (looks to be cut off). Works correctly on Windows and macOS.

Note that [System.AppDomain]::CurrentDomain.FriendlyName returns pwsh as expected.

[tmds]

@SteveL-MSFT do you have some info on how to reproduce this?

$ dotnet new console -o pwsh

Program.cs:

        static void Main(string[] args)
        {
            Console.WriteLine(Process.GetCurrentProcess().ProcessName);
        }

outputs:

$ dotnet run
pwsh

using:

$ dotnet --version
5.0.100-preview.1.20155.7

[SteveL-MSFT]

So in PowerShell, the code is calling GetProcessById()

[tmds]

        static void Main(string[] args)
        {
            int mypid = getpid();
            Console.WriteLine(Process.GetProcessById(mypid).ProcessName);
        }

        [DllImport("libc")]
        private static extern int getpid();

also outputs:

$ dotnet run
pwsh

[SteveL-MSFT]

Let me investigate this a bit after my meeting, wrote a simple C# program and it doesn't repro. The only change on the PowerShell side was moving from .NET Core 3.1 to .NET 5 preview.1

[SteveL-MSFT]

@tmds, ok, the problem is when Thread.CurrentThread.Name is set, then the process name uses that:

Thread.CurrentThread.Name = "foo"

[tmds]

In https://github.com/dotnet/coreclr/pull/27182 support was added for naming Linux threads.
The implementation is using pthread_setname_np.

The name set for the main thread shows up in the comm field in /proc/<pid>/stat (see http://man7.org/linux/man-pages/man5/proc.5.html) which we use to determine the ProcessName.

Previously changing the thread name was a no-op.
Maybe we should continue to no-op for changing name of the main thread?

cc @janvorli @lpereira

[janvorli]

@tmds I agree.

[lpereira]

Seems reasonable, @tmds. Might be a good idea to also mention in the docs that in some platforms the name might be truncated due to platform limitations (as mentioned by @SteveL-MSFT) to avoid surprises.

Although, to determine the ProcessName, maybe we could try using getauxval(AT_EXECFN)? That shouldn't be affected by the thread name.

[tmds]

Maybe we should continue to no-op for changing name of the main thread?

I'll make a PR for this change.

Although, to determine the ProcessName, maybe we could try using getauxval(AT_EXECFN)?

I was not aware of this API. We want to get this info for any process on the system. This is available in /proc under an auxv file. Unfortunately, it includes the pointer to the string, which isn't directly usable.