Exit code 130: The process was terminated by SIGINT

130 is 128 + 2, meaning SIGINT — the interrupt signal, normally produced by Ctrl-C. Inside Kubernetes it is unusual, because the platform sends SIGTERM rather than SIGINT.

Applies to: All Kubernetes versions, Linux nodes

What it means

Signal 2 is SIGINT, conventionally an interactive interrupt. Kubernetes never sends it: pod termination uses SIGTERM followed by SIGKILL. So a container exiting 130 was interrupted by something inside itself or by a person. The common sources are an interactive session — someone ran kubectl exec or kubectl attach and pressed Ctrl-C in a context where the signal reached PID 1 — or a supervisor process inside the container sending SIGINT to its child. It can also come from a shell wrapper that forwards signals it received.

Most common causes

• Someone pressed Ctrl-C in an attached session where the signal reached the container's main process.
• A process manager or supervisor inside the container sending SIGINT during its own shutdown.
• A test harness or entrypoint script that sends SIGINT deliberately.
• A wrapper script forwarding an interrupt to the process it launched.
• Debugging tooling attached to the process issuing an interrupt.

How to diagnose it

1. Check whether anyone was attached to the container at the time — audit logs record exec and attach subresource requests.
2. Read the container's process tree design: if PID 1 is a supervisor rather than the application, look at its configuration.
3. Confirm the code and reason in kubectl describe pod POD under Last State.
4. Check whether it happened during a rollout — if so, the more likely code is 143 and 130 points to something inside the container translating the signal.

How to fix it

1. Use kubectl exec rather than kubectl attach for interactive work, so Ctrl-C affects your shell rather than PID 1.
2. Have the application handle SIGINT the same way it handles SIGTERM — a clean shutdown either way is strictly better.
3. If a supervisor is sending SIGINT, either configure it to send SIGTERM or make the application treat both identically.
4. Use exec in entrypoint scripts so signals reach the real process directly rather than being relayed.

Notes

Seeing 130 in a production workload is worth investigating rather than dismissing, because Kubernetes did not cause it. Something inside the container, or a person, did.

Related

• Exit code 143 — Terminated by SIGTERM
• Exit code 137 — Killed by SIGKILL

Sources

• Linux manual page — signal(7)
• Kubernetes documentation — Pod Lifecycle: termination of pods
• GNU Bash Reference Manual — Exit Status