Remote MCP servers leave zombie processes after laptop sleep, blocking restart

[flfeurmou-indeed]

Problem

After laptop sleep/wake cycles, old thv processes sometimes remain running and continue holding their ports. When attempting to restart these servers, the new process fails with:

failed to listen: listen tcp 127.0.0.1:XXXXX: bind: address already in use

This happens even with #3417 (SO_REUSEADDR), because SO_REUSEADDR cannot override an actively running process, it only helps with sockets in TIME_WAIT state.

Observed behavior

1. Laptop goes to sleep with Datadog/Glean MCP servers running
2. Laptop wakes up
3. Old thv start <server> processes are still running (visible in ps aux | grep thv)
4. thv start <server> or thv restart <server> fails because the old process holds the port
5. Manual kill <pid> is required before the server can start

Environment

• macOS (Apple Silicon)
• Toolhive v0.7.x
• Remote MCP servers (Datadog, Glean) using OAuth

Possible solutions

1. PID file tracking: Store PID on start, check/kill stale process on restart
2. Better signal handling: Ensure processes terminate cleanly on SIGTERM/SIGHUP during sleep
3. Port-based cleanup: Before binding, check if another thv process holds the port and terminate it
4. Enhanced thv restart: Make restart explicitly kill the old process before starting new one

Workaround

Currently using a wrapper script that runs pkill -f "thv start <server>" before starting.

Related

• fix: improve stability of remote MCP server connections #3417 (SO_REUSEADDR for TIME_WAIT scenarios)
• Remote MCP servers fail after laptop sleep/wake cycles #3419 (parent issue for sleep/wake stability)

Happy to submit a PR if you'd like me to implement one of these solutions.

[flfeurmou-indeed]

Related issues that might inform the solution:

• Restart proxy processes after a reboot #431 - Restart proxy processes after reboot
• When the host restarts, ensure that we restart any workloads which were running #1169 - Restart workloads after host restart
• [BUG] stdio: transport enters zombie state when re-attachment fails #3383 - stdio transport zombie state
• Remote MCP servers fail after laptop sleep/wake cycles #3419 - Sleep/wake failures (SO_REUSEADDR fix)

These issues share a common theme around process lifecycle management. A unified solution (PID tracking, proper signal handling, or a system service) might address multiple issues at once.

Happy to consolidate if you'd prefer to track this under an existing issue.

[flfeurmou-indeed]

Created PR #3430 to fix this issue:

Changes:

1. isSupervisorProcessAlive now actually checks if the process is running (signal 0), not just if PID file exists
2. KillProcess now sends SIGKILL after SIGTERM if process doesn't terminate

This should handle zombie processes that survive laptop sleep and block restarts.