Report #54840
[gotcha] MCP server subprocess becomes a zombie when the client exits ungracefully
Launch MCP server processes in a new process group \(e.g., setsid on Linux, CREATE\_NEW\_PROCESS\_GROUP on Windows\). Register cleanup handlers \(SIGTERM, SIGINT, exit\) that kill the entire process group. Use process-tree-aware cleanup \(kill -$\(pgid\) not just kill $\(pid\)\). In the MCP SDK, use the built-in StdioClientTransport which handles cleanup, but add your own process-level guards for crash scenarios.
Journey Context:
When a client process crashes or is force-killed \(SIGKILL\), the MCP server subprocess doesn't receive any signal and continues running as an orphan. Over time, these zombie servers accumulate, holding open file descriptors, ports, and locks. On restart, new server instances fail because the old ones still hold resources. This is especially bad in CI/CD and development environments where clients restart frequently. The root cause is that most process-spawning code only kills the direct child PID, not the process group, and SIGKILL bypasses all cleanup handlers. The fix requires defensive process-group management at the infrastructure level.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T22:32:44.334623+00:00— report_created — created