How to fix Container exited with code 130 (SIGINT - Ctrl+C) in Docker

DockerBEGINNERLOWUpdated Dec 6, 2025· 195 views

Exit code 130 indicates that a Docker container was terminated by SIGINT (signal 2), typically triggered by pressing Ctrl+C. The exit code follows the Unix convention of 128 + signal number, so 128 + 2 = 130. This is normal behavior when manually stopping a container, not an error.

Quick fix

Fixes Container exited with code 130 (SIGINT - Ctrl+C)

# Check container exit code
docker inspect <container> --format='{{.State.ExitCode}}'
# Output: 130
  1. Understand that exit code 130 is expected behavior
  2. Run containers in detached mode to avoid accidental interrupts
  3. Use --init flag for proper signal handling
  4. Implement signal handlers in your application
docker — error
# Check container exit code
docker inspect <container> --format='{{.State.ExitCode}}'
# Output: 130
Container exited with code 130 (SIGINT - Ctrl+C)

What this error means

Exit code 130 is a standard Unix/Linux exit code that indicates a process was terminated by SIGINT (signal interrupt). SIGINT is signal number 2, and by Unix convention, when a process is killed by a signal, its exit code is calculated as 128 + signal number. Therefore, 128 + 2 = 130. When you press Ctrl+C on an attached Docker container, the terminal sends SIGINT to the container's main process (PID 1). If the process handles this signal and terminates gracefully, the container exits with code 130. This is expected behavior, not an error. However, there's an important nuance: a process running as PID 1 inside a container is treated specially by Linux. It ignores any signal with the default action unless the process is explicitly coded to handle it. This means some containers won't respond to Ctrl+C at all unless properly configured for signal handling.

Typical symptoms

  • Container shows 'Exited (130)' status after pressing Ctrl+C
  • docker ps -a shows exit code 130 for stopped containers
  • Container stops immediately when pressing Ctrl+C while attached
  • CI/CD pipeline reports exit code 130 when job is cancelled
  • docker-compose up exits with code 130 after Ctrl+C
  • Kubernetes pod terminated with exit code 130 after manual intervention

Common causes

  1. User pressed Ctrl+C while attached to a running container
  2. A script or process sent SIGINT (kill -2) to the container
  3. CI/CD system cancelled the job, sending SIGINT to running containers
  4. docker-compose received Ctrl+C and propagated SIGINT to services
  5. Container orchestrator sent interrupt signal during scaling or deployment
  6. Parent process terminated and sent SIGINT to child container processes

How to fix "Container exited with code 130 (SIGINT - Ctrl+C)"

1Understand that exit code 130 is expected behavior

Exit code 130 is not an error - it's the standard Unix way of indicating that a process was interrupted by SIGINT (Ctrl+C). If you intentionally stopped the container with Ctrl+C, this exit code is correct and expected.

bash
# Check container exit code
docker inspect <container> --format='{{.State.ExitCode}}'
# Output: 130

The container exited cleanly in response to your interrupt signal.

2Run containers in detached mode to avoid accidental interrupts

If you don't want to accidentally stop containers with Ctrl+C, run them in detached mode:

bash
# Run in detached mode (background)
docker run -d --name mycontainer myimage

# View logs without attaching
docker logs -f mycontainer

# Stop gracefully when needed
docker stop mycontainer

With detached mode, Ctrl+C only stops the log following, not the container itself.

3Use --init flag for proper signal handling

If your container doesn't respond to Ctrl+C properly, use the --init flag to add a minimal init process that handles signals correctly:

bash
docker run --init -it myimage

The init process (tini) runs as PID 1 and properly forwards signals to your application, ensuring clean shutdown behavior.

4Implement signal handlers in your application

For graceful shutdown, your application should handle SIGINT and SIGTERM:

python
# Python example
import signal
import sys

def signal_handler(signum, frame):
    print("Received signal, shutting down gracefully...")
    # Cleanup code here
    sys.exit(0)

signal.signal(signal.SIGINT, signal_handler)
signal.signal(signal.SIGTERM, signal_handler)
javascript
// Node.js example
process.on('SIGINT', () => {
  console.log('Received SIGINT, shutting down...');
  // Cleanup code here
  process.exit(0);
});
5Use exec form in Dockerfile for direct signal delivery

The exec form of CMD/ENTRYPOINT ensures your process receives signals directly:

dockerfile
# Exec form (recommended) - signals go directly to your app
CMD ["node", "server.js"]

# Shell form (not recommended) - signals go to /bin/sh
CMD node server.js

With shell form, /bin/sh runs as PID 1 and may not forward signals to your application.

6Handle exit code 130 in CI/CD pipelines

If your CI/CD pipeline treats exit code 130 as a failure, you may need to handle it explicitly:

bash
# Bash script example
docker run mycontainer || exit_code=$?
if [ "$exit_code" -eq 130 ]; then
  echo "Container was interrupted (expected)"
  exit 0
fi
exit $exit_code

Or in your CI configuration, mark 130 as an acceptable exit code for cancelled jobs.

Advanced notes

Signal propagation in docker-compose: When you press Ctrl+C on docker-compose up, compose catches SIGINT and sends SIGTERM (not SIGINT) to containers by default. The containers may exit with code 0 or 143 (128+15) rather than 130, depending on configuration.

PID 1 and signal handling: Linux treats PID 1 specially - it won't receive signals with default handlers. This is why many containers use init systems like tini or dumb-init. Without proper signal handling, Ctrl+C might appear to do nothing.

Difference between SIGINT and SIGTERM:
- SIGINT (2) - Interrupt signal, typically from Ctrl+C, exit code 130
- SIGTERM (15) - Termination signal, from docker stop, exit code 143

Graceful vs immediate shutdown: docker stop sends SIGTERM first, waits (default 10 seconds), then sends SIGKILL. Ctrl+C sends SIGINT immediately. Design your application to handle both gracefully.

Kubernetes considerations: When a pod is terminated, Kubernetes sends SIGTERM. Exit code 130 in Kubernetes usually indicates manual intervention (kubectl delete) or preStop hooks that triggered SIGINT.

Frequently asked questions

What does "Container exited with code 130 (SIGINT - Ctrl+C)" mean?
Exit code 130 is a standard Unix/Linux exit code that indicates a process was terminated by SIGINT (signal interrupt). SIGINT is signal number 2, and by Unix convention, when a process is killed by a signal, its exit code is calculated as 128 + signal number. Therefore, 128 + 2 = 130.
How do I fix "Container exited with code 130 (SIGINT - Ctrl+C)"?
Exit code 130 indicates that a Docker container was terminated by SIGINT (signal 2), typically triggered by pressing Ctrl+C. The exit code follows the Unix convention of 128 + signal number, so 128 + 2 = 130. This is normal behavior when manually stopping a container, not an error.
What causes "Container exited with code 130 (SIGINT - Ctrl+C)"?
User pressed Ctrl+C while attached to a running container A script or process sent SIGINT (kill -2) to the container CI/CD system cancelled the job, sending SIGINT to running containers
Is the "Container exited with code 130 (SIGINT - Ctrl+C)" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading