fix: scalable process lifecycle via PGID-based cleanup

[baudbot-agent]

Problem

Recurrent port 7890 conflicts causing bridge restart failures. Multiple processes compete for the same port after baudbot restart, and adding new services requires adding more manual cleanup code.

Root Cause

Manual process-name-based cleanup is brittle and does not scale:

• Each service requires explicit kill logic (tmux sessions, bridge PIDs, port holders, PID files)
• Orphaned processes survive if not explicitly tracked
• Race conditions between cleanup and respawn cause EADDRINUSE errors

Solution

Replace manual cleanup with UNIX process group (PGID) management:

1. start.sh: Launch control-agent via setsid (new process group), track PGID in ~/.pi/agent/control-agent.pgid
2. start.sh: On restart, kill -TERM -$OLD_PGID terminates the entire process tree automatically
3. startup-pi.sh: Remove all manual cleanup code (bridge pids, port checks, PID files) — handled by PGID
4. startup-pi.sh: Rename tmux session to baudbot-slack-bridge and add baudbot-* prefix-based tmux cleanup (tmux escapes PGID due to its own setsid)

Why tmux needs special handling

Tmux calls setsid() internally, giving it a separate PGID from the control-agent. So PGID-based cleanup doesn't reach tmux sessions. The fix uses a baudbot-* naming convention — one grep kills all agent tmux sessions, zero code changes needed when adding new ones.

Changes

start.sh:

• Replace bridge-specific cleanup (PID file, tmux kill, port release) with PGID-based lifecycle
• Track control-agent PGID, graceful SIGTERM → SIGKILL on restart
• Launch via exec setsid for process group isolation

startup-pi.sh:

• Remove ~45 lines of manual cleanup (bridge processes, port checks, PID files)
• Add baudbot-* prefix-based tmux session cleanup
• Rename tmux session: slack-bridge → baudbot-slack-bridge

Benefits

• ✅ Adding new services requires zero cleanup code
• ✅ No orphaned processes (PGID kills all children)
• ✅ No port conflicts from stale bridge processes
• ✅ Portable (POSIX process groups, no systemd dependency)
• ✅ Net reduction in code (~33 fewer lines)

[greptile-apps]

Greptile Summary

Added defensive cleanup to kill orphaned start-bridge.sh supervisor processes before starting the tmux-managed bridge. This prevents port 7890 conflicts when manual interventions or old deployments leave supervisor processes running.

Key changes:

• New cleanup step kills start-bridge.sh processes with SIGTERM, then SIGKILL if needed
• Follows existing pattern of graceful termination with fallback
• Addresses production issue where orphaned supervisors survived control-agent restarts

The fix is targeted and low-risk, though the pattern match could potentially be more specific to avoid false positives.

Confidence Score: 4/5

• Safe to merge with minimal risk - addresses a real production issue with defensive cleanup
• The change is straightforward and follows existing patterns in the script. The SIGTERM → SIGKILL approach is consistent with other cleanup logic. Minor concern about the pattern match being overly broad, but the risk of accidentally killing unrelated processes is low in this environment.
• No files require special attention - single file change with clear purpose

Important Files Changed

Filename	Overview
pi/skills/control-agent/startup-pi.sh	Added cleanup for orphaned start-bridge.sh supervisors to prevent port 7890 conflicts. Uses SIGTERM → SIGKILL pattern. Pattern match could be overly broad.

_{Last reviewed commit: cde4397}

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Pattern "start-bridge\.sh" will match any process with this substring in its command line, including:

• Editor sessions editing a file named start-bridge.sh
• grep or find commands searching for this file
• This very pgrep command itself (though || true handles that)

Consider making it more specific, e.g., "bash.*start-bridge\.sh" or "/start-bridge\.sh" to match only actual script executions.

Prompt To Fix With AI

This is a comment left during a code review.
Path: pi/skills/control-agent/startup-pi.sh
Line: 100

Comment:
Pattern `"start-bridge\.sh"` will match any process with this substring in its command line, including:
- Editor sessions editing a file named `start-bridge.sh`
- `grep` or `find` commands searching for this file
- This very `pgrep` command itself (though `|| true` handles that)

Consider making it more specific, e.g., `"bash.*start-bridge\.sh"` or `"/start-bridge\.sh"` to match only actual script executions.

How can I resolve this? If you propose a fix, please make it concise.

[benvinegar]

No longer applicable — this entire manual pgrep-based cleanup section has been removed. The branch now uses PGID-based process group management (kill -TERM -$OLD_PGID in start.sh), so we don't track individual process names at all.

_{Responded by bentlegen using anthropic/claude-sonnet-4-20250514.}