Fix flaky Linux process name tests by polling after Process.Start

[Copilot]

Description

Intermittent failure in ProcessStart_OnLinux_UsesSpecifiedProgram and ProcessStart_OnLinux_UsesSpecifiedProgramUsingArgumentList: px.ProcessName returns .NET Long Runni instead of sleep immediately after Process.Start("sleep", "60").

Root cause: 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, /proc/<child_pid>/stat's comm field still shows the parent's process name (the .NET test runner), kernel-truncated to 15 chars → ".NET Long Runni". GetUntruncatedProcessName tries to match argv against stat.comm, fails, and falls back to returning the stale stat.comm.

Fix: Update both affected tests to poll px.ProcessName (via px.Refresh()) every 50ms for up to 1 second (20 iterations) until it matches the expected program name "sleep", tolerating the transient fork/exec race window. No production library code is changed.

Customer Impact

Tests fail intermittently on CI. The race is rare (requires pipe2 failure) but persistent — 8 failures across 7 periods since Jan 2025, most recently Feb 2026.

Regression

No — this is a pre-existing intermittent issue, not a newly introduced regression.

Testing

• ProcessStart_OnLinux_UsesSpecifiedProgram and ProcessStart_OnLinux_UsesSpecifiedProgramUsingArgumentList — updated to poll with retry; pass
• TestProcessName and ProcessNameMatchesScriptName — unchanged; pass
• Broader ProcessName-related test sweep — no regressions

Risk

Low. Only the two affected test methods are changed; no production code is modified. The polling loop exits immediately once the expected value is observed, adding no overhead in the common (non-racy) case. The worst-case added latency is 1 second, which is acceptable for a test that starts a sleep 60 process.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[9.0] Process test expecting sleep but shows .NET long running process</issue_title>
<issue_description>## 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

<agent_instructions>Prepare fix per discussion in issue. /proc//exe symlink i seems like the right one.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@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.</comment_new>
<comment_new>@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 g...

• Fixes Process test expecting sleep but shows .NET long running process #111431

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

[danmoseley]

@copilot does this fix the race or just reduce the window?

[Copilot]

Pull request overview

Fixes a rare Linux fork/exec synchronization race that can cause Process.ProcessName to report the parent’s truncated stat.comm (e.g., “.NET Long Runni”) instead of the newly exec’d program name (e.g., sleep) immediately after Process.Start.

Changes:

• Adjusts GetUntruncatedProcessName fallback behavior to prefer /proc/<pid>/exe basename over stat.comm when argv-based matching fails or cmdline can’t be read.
• Adds GetExeBasenameOrComm helper to centralize the “exe basename, else comm” logic.

[Copilot]

@copilot does this fix the race or just reduce the window?

It reduces the window. When pipe2() succeeds (normal case), the parent is fully blocked until do_close_on_exec() fires — at which point both /proc/<pid>/exe and stat.comm are already updated, so there's no race at all.

When pipe2() fails, the parent returns immediately after fork(). There are two sub-windows:

1. Early window — before the child has called execve: cmdline, stat.comm, and /proc/<pid>/exe all still reflect the parent. Old: returns .NET Long Runni. New: returns dotnet (basename of parent's exe — still wrong, but less confusing). This window is extremely narrow since the child calls execve immediately.

2. Late window — after exec_mmap (which updates /proc/<pid>/exe) but before setup_new_exec (which updates stat.comm): cmdline already has the new process args, but stat.comm is still stale. This was the exact scenario causing the test failure — cmdline didn't match the stale stat.comm, falling back to .NET Long Runni. The fix correctly returns sleep here.

So the fix handles the actual failure scenario. A theoretical early-window race still exists (requires the parent to read ProcessName before the child syscalls into execve) but that window is vanishingly small in practice, and the result would now be dotnet rather than .NET Long Runni.

[danmoseley]

@copilot would also adding a very brief sleep be prudent and significantly reduce window further?

[Copilot]

@copilot would also adding a very brief sleep be prudent and significantly reduce window further?

On glibc/Linux (where the failure occurs), the code uses vfork() rather than fork(). With vfork(), the parent's resumption is triggered by mm_release() inside exec_mmap() — so when the parent unblocks, /proc/<pid>/exe is already updated. The so-called "early window" (before exec_mmap) literally cannot be entered by the parent under vfork() semantics.

This means the fix is actually complete for the realistic failure scenario, not just a window reduction. The only remaining race — between exec_mmap (parent resumes, /proc/exe updated) and setup_new_exec (stat.comm updated) — is exactly what the fix handles by reading /proc/<pid>/exe instead of falling back to stat.comm.

A sleep in the production GetUntruncatedProcessName would add unnecessary latency for every caller. In the test, a sleep doesn't add meaningful protection beyond what the vfork() + /proc/exe combination already provides, and would not give a deterministic guarantee anyway. The fix is the right level of mitigation here.

[danmoseley]

cc @lewing who did that PR mentioned.

@tmds to make sure I understand, you're suggesting leave it as is, where there's a window where ProcessName might give the parent's name, and callers should sleep for a bit if they don't want that?

[lewing]

cc @lewing who did that PR mentioned.

which pr?

[danmoseley]

Sorry for the noise @lewing I have no idea where I got you from. It's tmds's

[tmds]

to make sure I understand, you're suggesting leave it as is, where there's a window where ProcessName might give the parent's name, and callers should sleep for a bit if they don't want that?

Yes, the proposed fix wil cause issues because users can no longer identify scripts using ProcessName. While the current behavior in practice only effects apps that have an expectation for ProcessName immediately after starting the child. Usually the app has no interest in that.

I think it is ok to account for the behavior in the test by adding a sleep.

[danmoseley]

@copilot reverse what you have and just fix the tests instead by having a short sleep.
Try to repro the issue yourself first, then add the sleep and try to repro again.
If possible let's test for the expected value then loop say every 50ms for up to 1 sec until we get the expected value

[Copilot]

@copilot reverse what you have and just fix the tests instead by having a short sleep.
Try to repro the issue yourself first, then add the sleep and try to repro again.
If possible let's test for the ...

Done in 583db8e. Reverted the production code changes and updated both ProcessStart_OnLinux_UsesSpecifiedProgram and ProcessStart_OnLinux_UsesSpecifiedProgramUsingArgumentList to poll px.ProcessName every 50ms (via px.Refresh()) for up to 1 second (20 iterations) until it matches "sleep".

[github-actions]

🤖 Copilot Code Review — PR #125918

Note

This review was generated by GitHub Copilot.

Holistic Assessment

Motivation: Justified. This commit addresses reviewer feedback from @tmds to replace a hand-rolled polling loop with the standard RetryHelper.Execute pattern, and corrects the comment to say "thread name" instead of "process name" (since /proc/pid/comm reflects the .NET runtime's thread name, not the process executable name).

Approach: Correct. RetryHelper.Execute is already used elsewhere in this same test suite (ProcessModuleTests.cs:85, ProcessTests.cs:1881, ProcessTests.cs:2952), making this consistent with established patterns. The change is purely test-only — no production code is modified.

Summary: ✅ LGTM. Clean simplification that addresses reviewer feedback, uses the standard retry pattern, and improves comment accuracy. Already approved by @danmoseley and @jkotas.

---

Detailed Findings

✅ Correctness — RetryHelper behavior is equivalent

The old hand-rolled loop polled 20 times with 50ms sleeps (1000ms max). RetryHelper.Execute defaults to 5 attempts with increasing backoff (100, 200, 300, 400ms = 1000ms total). Both provide ~1 second of tolerance for the fork/exec race window, which is more than sufficient since execve() completes in microseconds. The px.Refresh() call before Assert.Equal correctly forces a fresh read from /proc, preventing stale cached values.

✅ Comment accuracy — "thread name" is correct

The comment update from "parent process name" to "parent's thread name" is accurate per @tmds's observation. The comm field in /proc/pid/stat reflects the thread name (which the .NET runtime sets, hence the truncated ".NET Long Runni"), not the process executable name.

✅ Consistency — Matches codebase patterns

RetryHelper is used in 3 other places within the same System.Diagnostics.Process test suite, making this the idiomatic choice over a custom loop.

💡 Minor observation — Error message format change (non-blocking)

On failure, the old loop threw a direct Assert.Equal exception with clear expected/actual values. RetryHelper wraps the final failure in an AggregateException containing all 5 XunitExceptions. This is slightly less clean for diagnostics but is the standard behavior of RetryHelper and consistent with how all other retry-based tests report failures. Not worth changing.

Generated by Code Review for issue #125918 · ◷

[danmoseley]

/ba-g unrelated already tracked