fix(zipapp): exec the interpreter so signals reach the Python process

[gfrankliu]

The self-executable py_zipapp_binary launcher (zip_shell_template.sh) runs
the interpreter as a child process. Signals sent to the PID the caller started,
e.g. by a process supervisor stopping a long-running service, only reach the
launcher shell, so the Python program never sees them. If the supervisor then
escalates to SIGKILL, the shell dies, the Python program keeps running as an
orphan (still holding its ports and stdio), and the EXIT trap that removes
the temporary extraction directory never runs, leaking the whole extraction on
every restart. This is the zipapp equivalent of #2043, which #2047 fixed for
the non-zip bootstrap; the launcher still had a TODO pointing at it.

To fix, exec the interpreter, as the non-zip bootstrap does. Because exec
replaces the shell, the EXIT trap can no longer clean up the temporary
directory, so just before exec the launcher starts a small detached watcher
that removes the directory once the PID (now the Python process) exits. Unlike
the trap, this also works after SIGKILL. The watcher is double-forked so it
is not a child of the Python program (which could otherwise reap it via
os.wait()), and its stdio is redirected so callers capturing the output
(e.g. $(zipapp)) don't wait on it. It compares the process state and start time (from /proc or ps), so a zombie or a reused PID can't delay cleanup, and it ignores the signals sent to a whole process group (a terminal's Ctrl-C, a hangup, or a supervisor stopping the group) so it survives to clean up. The trap stays in place until the exec,
so early failures still clean up. Nothing changes when
RULES_PYTHON_EXTRACT_ROOT or RULES_PYTHON_BOOTSTRAP_VERBOSE is set; those
directories are intentionally kept.

• Adds //tests/py_zipapp:zipapp_signals_test, which checks that the started
  PID is the Python process, that SIGTERM reaches it, that the extraction
  directory is removed after SIGTERM, after SIGKILL (before and after the
  process is reaped), and after SIGINT/SIGHUP/SIGTERM to the whole process
  group, and that exit codes propagate. Against the previous launcher it fails (39 != 35 for the PID
  check, and the SIGKILL case times out because the orphan keeps stdout open).

[Copilot]

Copilot review overview

🟡 Changes recommended

PID polling can delay cleanup indefinitely, and test cleanup may signal an unrelated reused PID.

Review effort: Balanced
Findings: 2

Open (2)

• Use reliable process identity checks instead of kill -0 polling · New
• Avoid killing reused PIDs after successful process reaping · New

What changed in this PR

Updates the zipapp launcher so signals reach Python directly while preserving temporary extraction cleanup.

Changes:

• Executes Python in place and adds a detached cleanup watcher.
• Adds signal, cleanup, PID, and exit-code tests.
• Documents the user-visible fix.

File	Description
python/​private/​zipapp/​zip_shell_template.sh	Adds exec and asynchronous cleanup.
tests/​py_zipapp/​BUILD.bazel	Registers signal-test targets.
tests/​py_zipapp/​zipapp_signals_test.py	Tests signals and cleanup behavior.
tests/​py_zipapp/​signals_main.py	Provides the test application.
news/​zipapp-exec-signals.fixed.md	Adds the release note.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[gfrankliu]

Good catch, fixed in d9a6687. The watcher now compares a process identity instead of kill -0: the state and start time from /proc/<pid>/stat on Linux, or ps -o stat=,lstart= elsewhere (e.g. macOS), falling back to kill -0 only if neither is available. A zombie counts as exited, and a reused PID has a different start time. Added test_extracted_files_removed_before_process_is_reaped, which SIGKILLs the process without reaping it; it failed with the kill -0 version and passes now.

[gfrankliu]

Agreed, fixed in d9a6687: the fallback kill of the reported Python PID is now only registered when it differs from proc.pid, i.e. the non-exec launcher case it exists for.