O Que É o Exit Code 137? Explicação
O exit code 137 significa que um processo foi encerrado por SIGKILL. É 128 + 9, e em CI a causa é quase sempre o out-of-memory killer.
Um step que termina em 137 não retornou esse número; ele foi encerrado. Entender a codificação diz exatamente o que aconteceu e por que geralmente não há stack trace para ler, o que transforma uma falha desconcertante em um diagnóstico claro.
A codificação 128 + N
Por convenção Unix, um processo encerrado pelo sinal N reporta o exit code 128 + N. O SIGKILL é o sinal 9, então 128 + 9 = 137. O mesmo esquema dá 143 para SIGTERM (15) e 130 para SIGINT (2). Qualquer código acima de 128 significa que um sinal, e não a lógica do programa, encerrou o processo.
Por que geralmente é OOM
O SIGKILL não pode ser capturado, bloqueado nem ignorado, então o kernel o reserva para forçar um processo a morrer imediatamente. Em runners com memória limitada, a origem mais comum de um kill forçado é o out-of-memory killer recuperando memória. É por isso que o 137 geralmente chega com apenas "Killed" e nenhum traceback.
Confirmando a causa
- Verifique o uso de memória do runner em torno da falha, ou o log do kernel por uma linha de oom-kill.
- Em containers, procure um status OOMKilled no container que saiu.
- Descarte um watchdog externo ou um literal kill -9 se a memória parecer saudável.
Transitório ou determinístico
Se o build sempre excede a memória do runner, o 137 é determinístico e a correção é mecânica: mais memória ou pico de uso menor. Se acontece apenas sob carga ou marginalmente, um retry em um runner novo muitas vezes o resolve, o que o torna transitório.
A perspectiva da Latchkey
Os managed runners com autocorreção da Latchkey tratam um OOM kill com exit code 137 como uma falha mecânica e automaticamente fazem retry, de modo que uma instabilidade de memória isolada não faça seu build falhar, enquanto builds consistentemente acima do orçamento ainda aparecem para dimensionamento correto.
Principais conclusões
- Exit code 137 = encerrado por SIGKILL (128 + 9).
- Em CI, é predominantemente o out-of-memory killer.
- Raramente há stack trace porque o SIGKILL não pode ser interceptado.
- Um pico marginal é transitório e passível de retry; uma escassez real exige mais memória.