Repository navigation
Prevent setup PTY test children from surviving a dead test harness #736
Description
This was generated by AI during triage.
Historical observation
During the 2026-10-16 triage session, 24 target/debug/thirdshift setup processes from several integration-test worktrees were found idle on PTYs for approximately 10–16 days. They were ended at the maintainer's direction. This report records that observation; those processes are no longer available for inspection, and no live reproduction was performed during this triage.
Current code and uncertainty
tests/support/mod.rs::Scenario::run_terminal creates a PTY and starts the child in a new session using setsid() and TIOCSCTTY. It wraps the child in TerminalCommand, whose Drop kills and waits for that immediate child. The fixture also bounds ordinary prompt and exit waits.
That cleanup should cover an assertion panic that unwinds normally. It cannot execute after abrupt death of the test-harness process. The historical observation is consistent with missing cleanup on harness death, but it does not establish which signal or lifecycle event originally left these children alive. Do not treat normal panic cleanup as wholly absent.
Requested outcome
Reproduce the lifecycle gap with a small isolated fixture that starts an actual setup PTY child, ends only its own fixture harness, and checks that no owned setup process remains. Cover ordinary completion, assertion unwinding, a bounded timeout, and abrupt harness termination separately. Establish the supported-platform cleanup contract before choosing a mechanism; clean up only fixture-owned processes and reap children where possible.
The resulting fix should keep setup's terminal behavior and existing interruption/terminal-restoration assertions intact. Report any platform limitations explicitly. Avoid blanket process-name kills or broad cleanup of temporary directories.
Related issues
- investigate why so many thirdshift files have accumulated in /tmp #569 tracks accumulated temporary files. These long-lived children may help explain retained fixtures, but a causal link has not been proven.
- Recover an open issue left in-progress by a Run that was killed outright #710 concerns dead production Runs and Claims. This report concerns integration-test child lifetime, so it is a separate scope.
Activity
JacobStephens2 commentedon Oct 21, 2026
Agent Brief
Category: bug
Summary: A
thirdshift setupchild started on a test PTY never outlives its testCurrent behavior:
The integration-test fixture that drives
thirdshift setupinteractively opens a PTY. It starts setup as a new session leader with the PTY as its controlling terminal, and wraps it in a guard that kills and reaps it when dropped. That covers a test that returns or unwinds normally. Nothing ends the child if the test process itself dies abruptly.Setup records SIGHUP, SIGINT and SIGTERM as an interruption rather than dying on them. Its input polling then ends it, as it does when stdin closes.
On 2026-10-16, 24
thirdshift setupprocesses from integration-test worktrees were found idle on PTYs, 10–16 days after their tests, and were ended by hand. They weren't inspected, so what left them is unknown. A closed PTY master would hang up the terminal and end setup, so idle children suggest the master stayed open, for example through an inherited descriptor, or that their test process never exited.Desired behavior:
A setup child started by the fixture ends when its test ends, however the test ends: normal completion, a failed assertion, a timeout, or abrupt death of the test process (SIGKILL). Cleanup acts only on processes the fixture started. Setup's terminal behavior is unchanged, and so are the existing interruption and terminal-restoration tests.
Key interfaces:
Scenario::run_terminal) and its child guard (TerminalCommand).Acceptance criteria:
Out of scope: