How to fix Exit Code 130 in Kubernetes

KubernetesBEGINNERLOWUpdated Dec 6, 2025· 134 views

Exit code 130 means the container received SIGINT (Ctrl+C). This is typically intentional user interruption, not an error. Verify if termination was expected or implement signal handling.

Quick fix

Fixes Exit Code 130

kubectl describe pod <pod-name>
  1. Determine if the termination was intentional
  2. Check restart policy if pod keeps restarting
  3. Implement SIGINT handling in your application
  4. Distinguish from actual errors
kubernetes — error
kubectl describe pod <pod-name>
Exit Code 130

What this error means

Exit code 130 indicates that a container was terminated by a SIGINT signal (signal 2). The exit code is calculated as 128 + 2 = 130. SIGINT is the standard interrupt signal sent when a user presses Ctrl+C. Unlike other exit codes, 130 is not an error—it indicates intentional interruption. This commonly occurs during interactive debugging sessions, manual process termination, or when kubectl commands themselves are interrupted.

Typical symptoms

  • Container exits with code 130 after Ctrl+C in interactive session
  • Pod shows Completed status with exit code 130
  • kubectl run or kubectl exec terminated by user shows code 130
  • Container restarts unexpectedly in development environments
  • CI/CD pipeline jobs cancelled show exit code 130
  • Logs show clean termination without errors

Common causes

  1. User pressed Ctrl+C during kubectl exec or kubectl run session
  2. Interactive process received manual SIGINT signal
  3. Parent process terminated child with SIGINT
  4. CI/CD system cancelled running job or pipeline
  5. Application does not handle SIGINT and exits immediately
  6. Debugging session ended by user interruption

How to fix "Exit Code 130"

1Determine if the termination was intentional

First, verify whether someone manually interrupted the process:

bash
kubectl describe pod <pod-name>

Check the Events section and Last State. If Reason shows "Completed" with exit code 130, it was likely a user-initiated Ctrl+C.

Review recent activity:
- Did someone run kubectl exec or kubectl attach?
- Was a CI/CD job cancelled?
- Did a developer interrupt a debugging session?

2Check restart policy if pod keeps restarting

If exit code 130 triggers unwanted restarts:

yaml
# For one-time tasks, prevent restarts
spec:
  restartPolicy: Never

# Or only restart on actual failures
spec:
  restartPolicy: OnFailure

Note: Deployments force restartPolicy: Always. Use Jobs if you need different restart behavior.

3Implement SIGINT handling in your application

For applications that need graceful interruption handling:

Python:

python
import signal
import sys

def handler(signum, frame):
    print("Received SIGINT, cleaning up...")
    # Cleanup logic
    sys.exit(0)  # Exit cleanly instead of 130

signal.signal(signal.SIGINT, handler)

Node.js:

javascript
process.on('SIGINT', () => {
  console.log('Received SIGINT, shutting down...');
  // Cleanup logic
  process.exit(0);
});
4Distinguish from actual errors

Exit code 130 (SIGINT) is different from error-indicating codes:

| Code | Signal | Meaning |
|------|--------|---------|
| 130 | SIGINT | User interrupt (Ctrl+C) - usually intentional |
| 137 | SIGKILL | Force kill - often OOMKilled |
| 143 | SIGTERM | Graceful termination request |

If you're seeing 130 unexpectedly, check for automated processes sending SIGINT rather than SIGTERM.

5Handle in CI/CD pipelines

In CI/CD systems, exit code 130 indicates job cancellation:

yaml
# GitLab CI example - handle interrupts
script:
  - |
    trap 'echo "Job cancelled, cleaning up..."; exit 0' INT
    ./long-running-task.sh

Some CI systems interpret code 130 as failure. Wrap commands to return 0 on interrupt if needed:

bash
./my-command || [ $? -eq 130 ] && exit 0

Advanced notes

Exit code 130 is expected behavior in interactive Kubernetes workflows. When running kubectl exec -it or kubectl run -it, pressing Ctrl+C sends SIGINT to the container process, resulting in exit code 130.

For debugging containers that exit with 130, check if automated tools or scripts are sending SIGINT. Some process managers incorrectly send SIGINT instead of SIGTERM for graceful shutdown.

In production, exit code 130 should be rare since interactive sessions are uncommon. If you see it frequently, investigate whether monitoring tools or automated processes are interrupting containers.

The container runtime preserves the exit code, so 130 indicates the application itself exited with that code (either by not handling SIGINT or by explicitly exiting with 130 after handling it).

Frequently asked questions

What does "Exit Code 130" mean?
Exit code 130 indicates that a container was terminated by a SIGINT signal (signal 2). The exit code is calculated as 128 + 2 = 130. SIGINT is the standard interrupt signal sent when a user presses Ctrl+C.
How do I fix "Exit Code 130"?
Exit code 130 means the container received SIGINT (Ctrl+C). This is typically intentional user interruption, not an error. Verify if termination was expected or implement signal handling.
What causes "Exit Code 130"?
User pressed Ctrl+C during kubectl exec or kubectl run session Interactive process received manual SIGINT signal Parent process terminated child with SIGINT
Is the "Exit Code 130" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading