Group Termination and Orphans

`subprocess.Popen.terminate()` and `subprocess.Popen.kill()` read like two strengths of one operation. On Unix they are two different signals, and what separates them is not how fast the child dies but whether the child gets to run any of its own code on the way out. ## What the two calls actually do Both are one-line wrappers around `Popen.send_signal()`. `send_signal()` first checks whether the child has already been reaped (if so it does nothing, because the pid may since have been recycled by the kernel onto an unrelated process), then calls `os.kill(self.pid, sig)`. `terminate()` passes `signal.SIGTERM`; `kill()` passes `signal.SIGKILL`. That is the whole implementation. Anything you can say about the two methods is a statement about the two signals. ## SIGTERM is a request SIGTERM is the conventional "please stop" signal, and it is deliverable to user code. A program can install a handler with `signal.signal(signal.SIGTERM, handler)` and use it to close a database connection, rename a temp file into place, remove a pid file, and exit with a status of its own choosing. It can also set the disposition to `signal.SIG_IGN` and ignore the signal outright, or block it while it is inside a critical section and take delivery later. That is the point of SIGTERM and also its limitation: `terminate()` is a polite request that a well-behaved program honours, not an assurance that the process is gone. A child that is wedged, that has ignored the signal, or that is blocked in a call the handler cannot interrupt will still be there afterwards. Code that sends SIGTERM and immediately assumes success is the single most common bug in this area. ## SIGKILL is not deliverable to user code SIGKILL is special-cased by the kernel: it cannot be caught, cannot be blocked and cannot be ignored. `signal.signal(signal.SIGKILL, ...)` raises `OSError` rather than installing anything. When SIGKILL is delivered, the kernel destroys the process. Nothing of the child runs: no signal handler, no `finally` block, no `atexit` callback, no `__del__`, no flush of buffered writes still sitting in the process's own memory. The practical consequences are entirely predictable, and an interviewer wants to hear you name them: a file the child was midway through writing stays truncated, a lock file or temp directory it would have removed stays on disk, an in-memory batch it had not yet written is lost. Those are the costs you are choosing to accept when you escalate. The one state SIGKILL cannot cut through is a process stuck in an uninterruptible kernel wait inside a driver — it dies as soon as that call returns, and not before. ## Both reach only the direct child Neither method touches anything except the one pid that `Popen.pid` holds. If the child is itself a wrapper — a shell started with `shell=True`, a launcher script, a supervisor — its own children receive nothing and keep running after the wrapper dies. Reaching a whole tree is a separate mechanism (a process group), not a stronger signal. Neither method reaps the child either. After signalling you still call `Popen.wait()`, both to let the kernel hand back the exit status and to know when the process is actually gone rather than merely signalled. ## Windows Windows has no POSIX signal delivery. There, `terminate()` and `kill()` are the same method: both ask the platform to terminate the process abruptly with an exit code. A Windows child therefore never gets the graceful path, and portable code that relies on a clean shutdown has to arrange one itself — an IPC message, a sentinel file, or a protocol on the child's stdin — rather than assuming SIGTERM semantics. ## Which one to use The default should always be `terminate()` first, then a bounded grace period in which you wait for the child, then `kill()` if it is still alive. Reaching for `kill()` immediately trades a corrupt output file for a couple of saved seconds, which is almost never the trade you want. Reaching for `terminate()` and never checking leaves you with a process you believe is dead and is not. When you need something other than those two signals — SIGINT to emulate Ctrl-C, SIGHUP to ask a daemon to reload, SIGUSR1 for an application-defined action — use `Popen.send_signal()` directly with the constant from the `signal` module. `terminate()` and `kill()` are just the two shortcuts the standard library chose to name.