What does exit code 137 from a Python CI step mean?

## Why one number has to carry two different outcomes A process can end in two fundamentally different ways: it can finish and hand back a status of its own choosing, or it can be killed by a signal it never got to respond to. The operating system keeps these apart cleanly — the wait status a parent retrieves records which case occurred and either the exit code or the signal number. A shell, though, exposes only a single number in `$?`, and a CI runner surfaces only that number as the step's result. The convention that squeezes both into one byte is **128 + N**: a process killed by signal N is reported as 128 plus N. So the numbers you actually meet in a build log decode like this: | reported | signal | what it usually means | |---|---|---| | 137 | 9, SIGKILL | out-of-memory kill, or a container memory limit; unkillable-process cleanup | | 143 | 15, SIGTERM | a supervisor, job timeout or orchestrator asked the process to stop | | 139 | 11, SIGSEGV | a memory fault, nearly always inside a native extension or the interpreter itself | | 134 | 6, SIGABRT | an abort from C-level code, often a failed assertion in a compiled library | | 130 | 2, SIGINT | an interrupt, typically Ctrl-C or a cancelled interactive run | The two that dominate real incidents are 137 and 143, and the difference between them is the whole diagnosis: 137 means something took the process away with no chance to react, while 143 means something asked politely and the process either declined or ran out of grace period. ## Reading 137 correctly The most common cause by far is memory. A step that trains, parses or holds a large working set grows past the memory the runner or container allows, and the kernel's out-of-memory killer picks it off. The signature is unmistakable once you know it: **no Python traceback in the log**. An out-of-memory condition Python itself notices raises `MemoryError` and prints a traceback; a kill at 137 leaves nothing, because the process was not running any more by the time anything could be written. Output truncated mid-line is another tell — the buffered tail was never flushed. The practical consequences follow directly. Retrying the step unchanged reproduces it, because nothing about the workload changed. Adding `try`/`except` around the code does nothing, because SIGKILL cannot be caught or handled. The fixes are all outside the program: raise the memory limit, shrink the working set, stream instead of loading, or split the job. 143 reads differently. Something sent SIGTERM — a job timeout, a deploy rolling the container, an operator stopping the service. Here the program *could* have responded, and if 143 shows up on a service that was supposed to shut down cleanly, the question is why it did not finish in the grace period before the follow-up kill. ## What Python can and cannot produce Python's own exit statuses are small and deliberate: 0 for success, 1 for an uncaught exception, and whatever integer you pass to `sys.exit()`. The interpreter never chooses 137 for you. That leads to the trap worth naming in an interview: `sys.exit(137)` is legal, and in a CI log it is **indistinguishable** from a genuine SIGKILL. An engineer who reads 137 will start hunting a memory problem that does not exist. The same applies to any code at or above 128, and to 126 and 127, which shells reserve for "found but not executable" and "command not found". The discipline is therefore to keep application exit codes in the range 1–125, and to give them meaning: for example 1 for an unexpected failure, 2 for bad usage, and a small set of distinct codes for conditions a supervisor should treat differently — say, a retryable upstream error versus a fatal configuration error. Remember too that only the low eight bits of the status survive, so a code above 255 wraps and can land in signal territory by accident: `sys.exit(400)` reports as 144, which reads like 128 + 16. ## Seeing the real distinction from Python When your own code supervises children, do not work with the flattened number at all — the wait status carries both facts, and the `os` module exposes the accessors for it: ```python import os pid = os.fork() if pid == 0: os.kill(os.getpid(), 9) _, status = os.waitpid(pid, 0) if os.WIFSIGNALED(status): sig = os.WTERMSIG(status) print(f"killed by signal {sig}; a shell would report {128 + sig}") else: print("exited with", os.WEXITSTATUS(status)) ``` That prints `killed by signal 9; a shell would report 137`, which is the convention made explicit: the 128 offset is bookkeeping the shell adds, not something the dying process reported. ## The interview-shaped answer Given "the step exited 137", a strong answer moves in three beats. First, decode it: 128 + 9, so the process was SIGKILLed and did not choose its own status. Second, name the likely cause and the confirming evidence: a memory limit or the OOM killer, confirmed by the absence of a traceback, truncated output, and the runner's or kernel's memory records. Third, state what will and will not help: raising the limit or reducing the working set will; a retry, a broader `except`, or a `finally` block will not, because nothing in the process ran after the signal arrived.