Repository navigation
macOS: waiting on a foreign Process object for the launcher's server never sees its exit #520
Description
What
On macOS, a consumer that hard-kills the server started by OpenCodeServer.StartAsync through its own Process object, and then waits on that object, never sees the exit. The pattern is Process.GetProcessById(server.ProcessId), then Kill(entireProcessTree: true), then WaitForExitAsync with a 10 s bound. The wait times out every time on the Intel Mac (macOS 15). The same app passes on Windows and Linux.
Evidence
The internal developer-experience round on the 2.0.32 nightlies, 2026-10-18 (the night round and both re-runs). App 03 restarts its own server mid-stream to test the event bus's reconnect.
It was first suspected to be the Stop-reap defect fixed in #518, but that is ruled out: the re-run on the nightly that contains #518 still times out in the same way, and StopAsync is not involved.
Not verified yet
The cause is not established. The candidates are:
- The SDK side: the launcher's own exit watch reaps the child it spawned (it spawns with
posix_spawn, notProcess.Start). A separateProcessobject that the consumer obtains for that pid may then have no way to observe the exit on macOS. - The .NET side: how .NET's exit detection on macOS behaves for a process that the
Processobject did not start.
The next step is a minimal reproduction on macOS, with and without the SDK launcher in the picture. Then decide whether this is SDK behaviour, a documentation note (a consumer should end the server through the SDK, not through a foreign Process object), or a .NET report.
Source: internal developer-experience evaluation of the 2.0.32 nightlies, 2026-10-18 (app 03, macOS).
Activity
Blind-Striker commentedon Oct 23, 2026
Mechanism found. It's an SDK defect on macOS, not a .NET one.
Measured on an M1 Mac running macOS 27.0 (26A428), arm64, with .NET SDK 10.0.402. The original report came from an Intel Mac on macOS 15, which is no longer available.
Kill(entireProcessTree: true)stops the tree before killing it. It sends SIGSTOP, "so it won't start additional children", and then SIGKILL (dotnet/runtime v10.0.0,Process.Unix.cs:110-112,KillTree). That is deliberate .NET behaviour, not a bug.waitid(P_PID, pid, WEXITED | WNOWAIT), and macOS returns from that call on the stop, withsi_code = CLD_STOPPED, even thoughWSTOPPEDwas not requested. A C probe showed this in 4 of 4 runs.waitpid(pid, WNOHANG)finds no exit yet and returns 0, so the watch records the exit as "unknown" and stops watching. Nothing reaps the child after that.Processobject never sees the exit. That object did not start the process, so it checks for exit withkill(pid, 0), and a zombie still answers.WaitForExitAsynctherefore never completes. A probe without the SDK, using the same watch logic, timed out 6 of 6 times.Controls:
waitidreturns at the exit and the child is reaped (8 of 8 runs).WEXITED-only wait, which is consistent with the app passing on Linux and Windows.A second symptom: the launcher reports the server as exited, with an unknown status, at the SIGSTOP. At that moment the server is only stopped.
Fix direction (to be specified): when the follow-up
waitpidfinds that the child hasn't exited, the child only stopped or continued. The watch must keep watching rather than end. The likely fallback is the watch's existing probe mode (kill(pid, 0)pluswaitpid(WNOHANG)). A POSIX regression row would stop and then kill a launched child, and assert that the real exit (signal 9) is reported and the child is reaped. That row runs on the macOS CI leg.test: the stopped-server row waits for the kernel's stop report
fix: the exit watch keeps watching a child that only stopped (macOS)
test: every branch of the stopped-server row asserts, and both rows d…
test: rows for the exit watch after a stop report (red first)
test: the stopped-server row waits for the kernel's stop report
fix: the exit watch keeps watching a child that only stopped (macOS)
test: every branch of the stopped-server row asserts, and both rows d…