When Popen.communicate(timeout=...) raises subprocess.TimeoutExpired, what is still running and what must you do?

## The exception ends your wait, not the child `Popen.communicate(timeout=...)` gives *your* call a deadline. When it expires, `subprocess.TimeoutExpired` propagates and everything about the child is exactly as it was: the process is running, its stdout and stderr pipes still exist, whatever it had already written is still sitting in the parent's buffers, and the parent still owns the obligation to reap it. Nothing was signalled, nothing was closed. That is why the documented recovery has two steps: ```python try: out, err = proc.communicate(timeout=30) except subprocess.TimeoutExpired: proc.kill() out, err = proc.communicate() ``` The `kill()` sends `SIGKILL` on POSIX (`TerminateProcess` on Windows). The **second** `communicate()` is not decoration: it reads the pipes to end-of-file and calls `Popen.wait`, which is what actually collects the exit status. A killed-but-unreaped child stays in the process table as a zombie, and `Popen.returncode` stays `None`, so any later `check_returncode`-style logic sees a process that neither succeeded nor failed. ## What goes wrong when you skip a step - **No kill at all** — you catch the timeout, log it, move on. The child keeps running, keeps writing, keeps consuming CPU. Repeat that under a scheduler and the box accumulates orphaned work until it falls over. - **Kill without the second communicate** — the signal is delivered but you never reap, so a zombie remains and the parent's read-end descriptors stay open. In a long-lived process this is a descriptor leak with a hang at the end of it. - **Kill and then `wait()` instead of `communicate()`** — safe only because the child is dying; if it were merely `terminate()`d and chose to keep writing, you would be back in the original deadlock, waiting on a child blocked against a full pipe. ## What the exception carries `subprocess.TimeoutExpired` exposes `cmd` and `timeout`, and on 3.14 the partial output read before the deadline is attached to `TimeoutExpired.stdout`. Two cautions: it is *partial*, so a parser that assumes complete output will misread it, and it is attached as **undecoded bytes even when the `Popen` was created with `text=True`**. Log it as bytes or decode it defensively; do not feed it to code expecting `str`. `subprocess.run` wraps this cleanup for you, but not identically on every platform: on timeout it kills the child, then on POSIX it waits, while on Windows it re-runs `communicate` to refill the exception's `stdout` and `stderr`. So `run` never leaks a child, and that is a good reason to prefer it whenever you do not need incremental control. ## Escalation, and what a timeout means to your system `Popen.kill()` is abrupt: `SIGKILL` cannot be caught, so the child gets no chance to flush a file, remove a lock or finish a database transaction. In production the usual shape is graceful-then-forceful — `Popen.terminate()` (`SIGTERM`), a short wait, then `Popen.kill()` if the process is still alive. Note that both signal only the direct child; a shell wrapper or a tool that spawned its own workers will leave descendants behind, which is a separate problem with a separate solution. The policy question matters as much as the mechanics. Consider a ticket-triage bot that shells out to a classifier over a 6,800-row batch with a 30-second budget. The batch grows, the classifier stops finishing in time, and the `except subprocess.TimeoutExpired` branch quietly falls back to the previously cached scores. Every run now serves a stale cached value; the dashboard is green because no exception escaped, and triage silently degrades for days. The lesson is that a timeout is a failure with a cause, not a routing decision: increment a counter, log the command and the partial output, and make the fallback visibly distinct from a fresh result. Set the deadline from the work's real distribution rather than a round number, and remember that a hard timeout is also your last defence against the pipe-buffer deadlock — with one, an unbounded hang becomes a bounded, alertable error. ## Interview shape Say the exception did not touch the child; give the kill-then-drain-then-reap sequence; mention that `subprocess.run` does it for you; then add the escalation and the alerting policy. The candidates who stop after `proc.kill()` are the ones who leave zombies in production.