What does a negative multiprocessing.Process.exitcode mean?

### The three shapes of an exit status When you start a `multiprocessing.Process`, the parent keeps a handle on a real operating-system child process. `Process.exitcode` is the parent's view of how that child ended, and it is only meaningful once the child has actually terminated — before `start()`, and while the child is still running, the attribute reads `None`. Calling `join()` (or polling `is_alive()`) is what makes the value settle. Once the child is gone, the value follows the underlying wait-status convention, flattened into a single signed integer: * **`0`** — the child ran its target function to the end and exited normally. * **a positive integer** — the child terminated itself with that status. `sys.exit(3)` inside the child yields `3`. An uncaught exception in the target function yields `1`: multiprocessing catches it in the child's bootstrap, prints the child's traceback to that child's stderr, and exits with status 1. Note that the exception object itself does not travel back through `Process` — only the number does. `Process` gives you no result channel, so any diagnosis has to come from the child's own output or from a queue you set up yourself. * **a negative integer `-N`** — the child was killed by signal number `N` and never got to run any Python code afterwards. ### Why negative is the interesting case The negative case is the one interviewers are actually probing, because it is the only one that means the child had no say. Nothing in the child unwound: `try/finally` blocks did not run, context managers did not exit, `atexit` callbacks did not fire, buffered `print` output was never flushed, temporary files were never removed, and any lock the child held in shared state stayed held. That is why a crashed worker so often leaves the rest of the system in a strange state rather than simply producing a missing result. The two negatives you meet most often in real systems are: * **`-9`** — the child was hard-killed. On Linux this is very frequently the kernel's out-of-memory killer choosing the fattest process on the box, which under memory pressure is usually a worker. It is also what `Process.kill()` does, and what a container runtime does when a memory limit is exceeded. * **`-11`** — a segmentation fault, which in Python effectively always means a bug in a compiled extension module or in the C library underneath it, since pure Python cannot segfault by itself. A `-15` normally means somebody asked politely first: that is what `Process.terminate()` sends, and it is also the signal an orchestrator sends before escalating to a hard kill. ### Reading it correctly Two mistakes are common. The first is treating `exitcode` as a *result*: it is a disposition, not a return value, and a child that computed the wrong answer perfectly happily still exits `0`. The second is checking it too early. `exitcode` is `None` while the child lives, so `if p.exitcode:` before a `join()` silently reads as false and hides the failure. Join first (optionally with a timeout), then inspect. A useful pattern in a supervisor loop is to branch on the sign rather than the value: zero means done, positive means the child raised or exited deliberately and its own traceback is in the log, negative means the child was killed from outside and you should be looking at memory limits, native extensions, or whoever sent the signal — not at your Python traceback, because there will not be one. ### Cleanup is a separate concern Because a negative exit means no in-child cleanup ran, the parent has to own anything that must survive a kill. That means the parent removing scratch files it can name, the parent releasing shared resources, and the parent deciding whether the task is safe to retry. It also means designing tasks to be idempotent, since "killed at an unknown point" is exactly the state where a half-applied side effect is possible.