How to fix Exit Code 130 in Kubernetes

First, verify whether someone manually interrupted the process:

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?

If exit code 130 triggers unwanted restarts:

# 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.

For applications that need graceful interruption handling:

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:

process.on('SIGINT', () => {
  console.log('Received SIGINT, shutting down...');
  // Cleanup logic
  process.exit(0);
});

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.

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

# 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:

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