Process test expecting sleep but shows .NET long running process

[carlossanlop]

Build Information

Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=916912
Build error leg or test failing: net9.0-linux-Release-x64-coreclr_checked-Ubuntu.2204.Amd64.Open

Error Message

{
  "ErrorMessage" : ["Expected:", "sleep", ".NET Long Runni"],
  "BuildRetry" : true,
  "ExcludeConsoleLog" : false
}

• PR: [manual] Merge release/9.0-staging into release/9.0 (second pass) #111422
• Queue: Libraries Test Run checked coreclr linux x64 Release
• Job result: https://dev.azure.com/dnceng-public/public/_build/results?buildId=916912&view=logs&j=fe27627b-bd13-56b8-97c3-9bb28451d0b9&t=09d463f5-5a24-5ac9-897c-9929934ad820
• Log file: https://helixr1107v0xd1eu3ibi6ka.blob.core.windows.net/dotnet-runtime-refs-heads-release-90-staging-76ca6898836a48668c/System.Diagnostics.Process.Tests/1/console.1ee5f3c8.log?helixlogtype=result
• Output:

    System.Diagnostics.Tests.ProcessTests.ProcessStart_OnLinux_UsesSpecifiedProgram [FAIL]
      Assert.Equal() Failure: Strings differ
                 ↓ (pos 0)
      Expected: "sleep"
      Actual:   ".NET Long Runni"
                 ↑ (pos 0)
      Stack Trace:
        /_/src/libraries/System.Diagnostics.Process/tests/ProcessTests.Unix.cs(354,0): at System.Diagnostics.Tests.ProcessTests.ProcessStart_OnLinux_UsesSpecifiedProgram()
           at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
        /_/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs(57,0): at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=916912
Error message validated: [Expected: sleep .NET Long Runni]
Result validation: ❌ Known issue did not match with the provided build.
Validation performed at: 1/14/2025 6:55:20 PM UTC

Report

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	0

[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.

[adamsitnik]

I've taken a look at the test implementation and I can't see any reason why it would fail like this (sleep is a native Linux utility, not a .NET command line tool).

runtime/src/libraries/System.Diagnostics.Process/tests/ProcessTests.Unix.cs

Lines 344 to 363 in 5a395ed

	[Fact]
	[PlatformSpecific(TestPlatforms.Linux)]
	public void ProcessStart_OnLinux_UsesSpecifiedProgram()
	{
	const string Program = "sleep";
	using (var px = Process.Start(Program, "60"))
	{
	try
	{
	Assert.Equal(Program, px.ProcessName);
	}
	finally
	{
	px.Kill();
	px.WaitForExit();
	}
	Assert.True(px.HasExited);
	}
	}

For now I am going to move it to Future. If it starts failing more often we can invest more time into that.

[danmoseley]

Note

This analysis was generated with the assistance of GitHub Copilot.

Root Cause Analysis: Fork/Exec Race Condition

This appears to be a race condition between fork() and execve() in the child process.

The test does:

using (var px = Process.Start("sleep", "60"))
{
    Assert.Equal("sleep", px.ProcessName);  // immediately after Start
}

On Linux, Process.Start uses fork() + execve(). The Process object (with the child PID) is returned after fork() but potentially before execve("sleep") completes in the child. During that window:

1. /proc/<child_pid>/stat — the comm field still shows the parent's process name (the .NET test runner), kernel-truncated to 15 chars → ".NET Long Runni"
2. /proc/<child_pid>/cmdline — still has the parent's argv
3. GetUntruncatedProcessName tries to match argv[0]/argv[1] against stat.comm as a prefix, fails because neither matches "sleep", and falls back to returning stat.comm = ".NET Long Runni"

This is intermittent because it only fails when the child hasn't completed execve by the time ProcessName is read — more likely under CPU pressure on CI machines.

Possible Fixes

• Retry/poll ProcessName until it stops matching the parent's name (or matches the expected value)
• Check /proc/<pid>/exe symlink instead, which atomically reflects the exec'd binary
• Add a brief delay before the assert (crude but effective)

Related

This is a duplicate of #106595 (same test, same failure mode).

[danmoseley]

Note

This analysis was generated with the assistance of GitHub Copilot, using the known-issue-history skill.

Failure History

Issue #111431 has no meaningful hit count history (only 1 edit, all zeros). The tracking has been on the original issue #106595 instead, which shows:

• 8 failure events across 7 failure periods since Jan 2025
• Peak 24h count is always just 1 (occasionally 2) — a rare, timing-sensitive failure
• Failures occur roughly every 1–3 months
• Last failure: Feb 23, 2026 (26 days ago) — still active
• 1-month count never exceeds 2

Failure Periods (#106595)

#    Start           End             Peak 24h   Peak 1mo
1    2025-01-14      2025-02-13           1          2
2    2025-02-22      2025-03-22           1          1
3    2025-04-10      2025-05-10           1          1
4    2025-05-14      2025-06-13           1          1
5    2025-06-19      2025-07-31           1          2
6    2025-10-07      2025-11-06           1          1
7    2026-02-23      2026-03-02           1          1

This pattern is consistent with the fork/exec race condition described above — rare enough to be timing-dependent, but persistent enough that it won't resolve without a test fix.