The MCP Server I Thought I Killed Was Still Holding the Port: 84 Teardown Trials

Process-group targeting hits 0% — until setsid

Next, target the whole group. The tree was started with start_new_session=True, so everything should share one process group.

os.killpg(top.pid, signal.SIGTERM)

Orphan rate 0%. Port released in a median of 10.4ms, p90 10.5ms. Twelve clean teardowns out of twelve.

I nearly stopped there and wrote "use killpg" as the conclusion.

Then I ran the condition where the leaf calls os.setsid() itself — something daemonizing servers and signal-averse runtimes genuinely do.

Orphan rate went back to 100%.

The moment a process calls setsid(), it becomes the leader of a new session and a new process group. Its group ID no longer matches its parent's, so killpg simply doesn't reach it. The parent-child relationship is untouched; only signal delivery breaks.

Which means process-group targeting rests on an assumption you don't control: that the child stays in your group. MCP servers are somebody else's code. You don't get to make that promise on their behalf.

What the grace period was hiding

The common production pattern is two-stage: send SIGTERM, wait a grace period, escalate to SIGKILL if anything is left. I measured that too — SIGTERM to the top PID, 500ms grace, then a group-wide SIGKILL.

Against a normal child: 0% orphans. But the median time to port release was 516.9ms.

The breakdown is what stopped me. Zero of twelve processes exited during the grace window. All 500ms were spent every time, and the only thing that actually worked was the final SIGKILL.

A grace period is supposed to give a process time to shut down politely. Here the SIGTERM never reached the leaf, so waiting changed nothing. The grace window was doing one job: hiding the fact that the signal was misdelivered, for exactly 500ms.

When the signal does land, shutdown takes 10.4ms. We were paying a 50x penalty to conceal a delivery failure.

And against a setsid child, the two-stage pattern still orphaned 100% of the time. SIGKILL is group-targeted too. Escalating to a stronger signal doesn't help when the address is wrong.

Twelve trials per condition. "Port still held" is the share of trials where the same port could not be re-bound immediately after teardown returned.

Walking ppid links to build your own target list

If group IDs aren't trustworthy, use something that is. setsid() changes the session and the process group. It does not change the ppid.

Read ppid from every entry under /proc, rebuild the tree, and you can enumerate descendants no matter which group they wandered into.

"""Stop MCP servers started as child processes, without leaving anything behind."""
import os
import signal
import time
 
 
def _read_stat(pid):
    """Return (ppid, starttime) from /proc/<pid>/stat, or None if unreadable."""
    try:
        with open(f"/proc/{pid}/stat", "r") as f:
            raw = f.read()
    except (FileNotFoundError, ProcessLookupError, PermissionError):
        return None
    # comm can contain spaces and ')', so split on the last ') '
    try:
        fields = raw.rsplit(") ", 1)[1].split()
    except IndexError:
        return None
    return int(fields[1]), int(fields[19])      # ppid, starttime
 
 
def _is_live(pid, starttime):
    """Liveness excluding zombies, with a PID-reuse guard."""
    st = _read_stat(pid)
    if st is None or st[1] != starttime:
        return False                            # dead, or a different process reusing the PID
    try:
        with open(f"/proc/{pid}/cmdline", "rb") as f:
            return len(f.read()) > 0            # zombies keep /proc but empty cmdline
    except OSError:
        return False
 
 
def snapshot_tree(root_pid):
    """Collect descendants of root_pid as (pid, starttime), leaves first."""
    children, meta = {}, {}
    for entry in os.listdir("/proc"):
        if not entry.isdigit():
            continue
        pid = int(entry)
        st = _read_stat(pid)
        if st is None:
            continue
        children.setdefault(st[0], []).append(pid)
        meta[pid] = st[1]
    ordered, stack = [], [root_pid]
    while stack:
        pid = stack.pop()
        if pid in meta:
            ordered.append((pid, meta[pid]))
        stack.extend(children.get(pid, []))
    return list(reversed(ordered))              # kill leaves before their parents
 
 
def terminate_tree(root_pid, grace=0.5, poll=0.01):
    """SIGTERM every descendant, SIGKILL only what outlives the grace window.
 
    Returns: (targets, forced_kills)
    """
    targets = snapshot_tree(root_pid)
    if not targets:
        return 0, 0
    for pid, _ in targets:
        try:
            os.kill(pid, signal.SIGTERM)
        except (ProcessLookupError, PermissionError):
            pass
    deadline = time.monotonic() + grace
    while time.monotonic() < deadline:
        if not any(_is_live(pid, st) for pid, st in targets):
            return len(targets), 0
        time.sleep(poll)
    killed = 0
    for pid, st in targets:
        if _is_live(pid, st):
            try:
                os.kill(pid, signal.SIGKILL)
                killed += 1
            except (ProcessLookupError, PermissionError):
                pass
    return len(targets), killed

Those are the last two rows of the table. Normal child or setsid child, the result is the same: 0% orphans, 10.8ms to release. Not one target ever reached the SIGKILL stage. When the address is right, the grace window costs almost nothing.

Killing leaves first matters. Remove a parent and every surviving child gets reparented to PID 1, which erases the link you were about to follow. Enumerate once, before any signal goes out, then treat that array as your complete target list.

The starttime comparison covers the window between enumeration and kill where a PID could be recycled. At tens of milliseconds per teardown, that window is small. It still felt wrong to leave a path open that could signal an unrelated process.

Zombies were corrupting my liveness check

The first time I measured the sweep, the median came out at 505.9ms.

The full grace window, consumed. But I was walking ppid links, so the targets had to be correct. I spent a while suspecting kill return values and permissions.

The bug was on the observation side, not the teardown side. My liveness check was os.path.exists(f"/proc/{pid}").

An exited process stays a zombie until its parent reaps it, and zombies keep their /proc entry. The launcher was exiting at the same moment, so nothing was left to reap the leaf. The directory sat there until the grace window expired.

The server had actually died in about 10ms. The port had been free the whole time. I was staring at the shell of a dead process.

Switching the check to "cmdline is non-empty" dropped the median to 10.8ms — zombies clear their cmdline, so only real processes count.

The lesson generalizes: teardown correctness depends on delivery and observation. Get delivery right but observation wrong, and a correct implementation looks slow. Get observation wrong in the other direction, and you report success on processes that are still running. That second failure is exactly what the first three conditions were doing.

Choosing between them

If every server in the tree is code you wrote, a process-group SIGTERM is enough. It finishes in 10.4ms and it's one line. You can guarantee nobody calls setsid() only inside your own repository.

The moment you start a third-party MCP server, the ppid-based sweep earns its keep. The extra cost is one enumeration pass, and teardown time barely moved.

If you already run a grace-then-escalate teardown, instrument it once: count how many processes actually exit during the grace window. If that number sits at zero, the grace period isn't a safety margin. It's a place for misdelivered signals to hide.

And whatever you build, give yourself one external signal — a port, a lock file, a socket. Process liveness can be fooled by zombies. "Does the next bind() succeed?" cannot. That single check is the reason the differences between strategies showed up as cleanly as they did.

For the startup half of the same lifecycle, I measured the numbers in Startup Dropped to 3ms, and the First Turn Saw Zero Tools and I Measured Before Writing a Number: MCP Connect and Tool Calls Differed by 486x.

One stuck server this morning, and the most stubborn thing I found was my own assumption about what "stopped" meant.