How to fix Exited (137) - Container was killed by SIGKILL in Docker

First, determine if memory exhaustion caused the termination:

docker inspect --format='{{.State.OOMKilled}}' <container_name_or_id>

If this returns true, the container was killed by the OOM killer. You can also check the full state:

docker inspect --format='{{json .State}}' <container_name_or_id> | jq

Look for:
- "OOMKilled": true - Confirms OOM as the cause
- "ExitCode": 137 - Confirms SIGKILL termination

If OOMKilled is false, the container was killed externally (docker stop/kill, orchestrator, etc.).

Check system logs for OOM events or other termination signals:

# Check kernel messages for OOM killer activity
dmesg | grep -i "killed process"

# Check system logs
journalctl -u docker --since "1 hour ago" | grep -i kill

# View Docker daemon events
docker events --since 30m --filter event=die

Check your container logs:

docker logs <container_name_or_id> --tail 100

Look for patterns:
- Logs end abruptly without shutdown messages = SIGKILL (no chance to log)
- "Received SIGTERM, shutting down..." followed by timeout = Graceful shutdown timeout
- Memory-related warnings from your application = Approaching OOM

If OOM is suspected, analyze your container's memory consumption:

# Real-time memory stats
docker stats <container_name_or_id>

# Check memory limit set on container
docker inspect --format='{{.HostConfig.Memory}}' <container_name_or_id>

A value of 0 means no limit is set. To see the limit in human-readable form:

docker inspect <container_name_or_id> | grep -A5 '"Memory"'

Watch the MEM USAGE / LIMIT column in docker stats. If usage approaches the limit before crashes, OOM is likely the cause.

If OOM is confirmed, increase the container's memory allocation:

# Run with higher memory limit
docker run --memory=2g --memory-swap=2g <image>

For Docker Compose:

services:
  myapp:
    image: myimage:latest
    deploy:
      resources:
        limits:
          memory: 2G
        reservations:
          memory: 1G

For Docker Desktop (Windows/Mac): Go to Settings > Resources and increase the Memory allocation for the Docker VM.

Important: Also tune your application's runtime:
- Java: -XX:MaxRAMPercentage=75.0
- Node.js: NODE_OPTIONS="--max-old-space-size=1536"
- Go: GOMEMLIMIT=1500MiB

If your container is being killed due to shutdown timeout, implement proper signal handling:

Node.js example:

process.on('SIGTERM', () => {
  console.log('Received SIGTERM, shutting down gracefully...');
  server.close(() => {
    console.log('Server closed');
    process.exit(0);
  });
});

Python example:

import signal
import sys

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

signal.signal(signal.SIGTERM, handle_sigterm)

Shell script fix using exec:

# Instead of
CMD ["./start.sh"]

# Use exec to replace shell process
CMD ["./start.sh"]
# In start.sh:
exec python app.py  # exec ensures signals reach the app

If your application needs more time for graceful shutdown:

# Stop with longer timeout (30 seconds)
docker stop --time=30 <container_name_or_id>

For Docker Compose:

services:
  myapp:
    image: myimage:latest
    stop_grace_period: 30s

Or use the command line:

docker-compose stop --timeout 30

Note: Very long timeouts can slow down deployments and restarts. Aim to make your application shut down faster rather than extending timeouts indefinitely.

If running in Kubernetes or CI/CD, check those systems:

Kubernetes: Check if the pod was evicted or terminated:

kubectl describe pod <pod_name>
kubectl get events --field-selector involvedObject.name=<pod_name>

Look for:
- OOMKilled reason in container status
- Eviction events due to node pressure
- Failed liveness/readiness probes

CI/CD pipelines: Check for:
- Job timeout settings
- Pipeline cancellation
- Cleanup policies

Docker Swarm:

docker service ps <service_name> --no-trunc