How to fix Container was killed with SIGKILL in Docker

What this error means

The "Container was killed with SIGKILL" message indicates that your Docker container received the SIGKILL signal (signal number 9), which causes immediate and unconditional termination. Unlike SIGTERM, SIGKILL cannot be caught, blocked, or ignored by the process - the kernel forcefully terminates it. When a container exits due to SIGKILL, it will have exit code 137 (calculated as 128 + 9, where 9 is the signal number). This exit code is the key indicator that distinguishes a SIGKILL termination from other types of container failures. SIGKILL is typically a last resort signal used when: 1. A process doesn't respond to SIGTERM within a grace period 2. The system's OOM (Out of Memory) killer needs to free memory urgently 3. An administrator or orchestration system needs to force-stop a container 4. Docker's stop command times out waiting for graceful shutdown The abrupt nature of SIGKILL means the application has no opportunity to perform cleanup operations like closing database connections, flushing buffers, or saving state.

Typical symptoms

• Container exits with exit code 137
• Logs show 'Killed' message without application-level error
• docker inspect shows the container was killed by signal 9
• Application data may be corrupted or incomplete due to abrupt termination
• Container restarts repeatedly if restart policy is set
• No graceful shutdown logs from application (shutdown hooks not executed)
• dmesg may show OOM killer messages if memory-related

Common causes

1. docker stop command timed out waiting for SIGTERM response (default 10 seconds)
2. OOM killer terminated the container due to memory exhaustion
3. Manual docker kill command was issued
4. Orchestration system (Kubernetes, Swarm) forcefully terminated the container
5. Application doesn't handle SIGTERM signal and ignores shutdown requests
6. Process running as PID 1 with shell form CMD/ENTRYPOINT doesn't forward signals
7. System shutdown or Docker daemon restart forced container termination
8. Host system under memory pressure killing processes

How to fix "Container was killed with SIGKILL"

# Check exit code (137 = SIGKILL)
docker inspect --format='{{.State.ExitCode}}' <container_name>

# Check if OOM killed
docker inspect --format='{{.State.OOMKilled}}' <container_name>

# View container state details
docker inspect --format='{{json .State}}' <container_name> | jq

# Check system logs for OOM events
dmesg | grep -i "killed process"
dmesg | grep -i "out of memory"

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

  // Force exit after 10 seconds if graceful shutdown fails
  setTimeout(() => {
    console.error('Graceful shutdown timed out, forcing exit');
    process.exit(1);
  }, 10000);
});

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)

sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGTERM)

go func() {
    <-sigChan
    log.Println("Received SIGTERM, shutting down...")
    // Cleanup and shutdown
    os.Exit(0)
}()

# Runs as: /bin/sh -c "node server.js"
# PID 1 is sh, not node - signals don't reach your app
CMD node server.js
ENTRYPOINT python app.py

# Runs directly, your app is PID 1
CMD ["node", "server.js"]
ENTRYPOINT ["python", "app.py"]

#!/bin/bash
# entrypoint.sh

# Setup code here...

# Use exec to replace shell with your app
exec node server.js

# Give 30 seconds instead of default 10
docker stop --time=30 <container_name>

# Or wait indefinitely for graceful shutdown
docker stop --time=-1 <container_name>

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

# Set default stop signal and timeout
STOPSIGNAL SIGTERM
# Note: STOPSIGNAL only changes the signal, not the timeout

spec:
  terminationGracePeriodSeconds: 30

# Install tini
RUN apt-get update && apt-get install -y tini

# Use tini as entrypoint
ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["node", "server.js"]

FROM alpine:latest
RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["./myapp"]

RUN apt-get update && apt-get install -y dumb-init
ENTRYPOINT ["/usr/bin/dumb-init", "--"]
CMD ["python", "app.py"]

docker run --init myimage

services:
  myapp:
    image: myimage
    init: true

docker run --memory=2g --memory-swap=2g myimage

docker stats <container_name>

docker run --memory=1g -e NODE_OPTIONS="--max-old-space-size=768" myapp

docker run --memory=2g -e JAVA_OPTS="-XX:MaxRAMPercentage=75.0" java-app

# Watch for container kill events in real-time
docker events --filter 'event=kill'
docker events --filter 'event=oom'

# List recently exited containers with exit codes
docker ps -a --filter "status=exited" --format "{{.Names}}: {{.Status}}"

Advanced notes

# See what process is PID 1 in container
docker exec <container> ps aux

# Check if your app is actually PID 1
docker exec <container> cat /proc/1/cmdline

STOPSIGNAL SIGQUIT  # For nginx graceful shutdown

docker run --stop-signal=SIGQUIT nginx

Frequently asked questions

What does "Container was killed with SIGKILL" mean?

The "Container was killed with SIGKILL" message indicates that your Docker container received the SIGKILL signal (signal number 9), which causes immediate and unconditional termination. Unlike SIGTERM, SIGKILL cannot be caught, blocked, or ignored by the process - the kernel forcefully terminates it. When a container exits due to SIGKILL, it will have exit code 137 (calculated as 128 + 9, where 9 is the signal number).

How do I fix "Container was killed with SIGKILL"?

This error occurs when a Docker container receives the SIGKILL signal (signal 9), causing immediate termination without graceful shutdown. Common causes include OOM killer, docker stop timeouts, manual kill commands, or orchestration systems forcefully terminating containers.

What causes "Container was killed with SIGKILL"?

docker stop command timed out waiting for SIGTERM response (default 10 seconds) OOM killer terminated the container due to memory exhaustion Manual docker kill command was issued

Is the "Container was killed with SIGKILL" error serious?

Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Related errors

• Container did not respond to SIGTERM within timeout

  How to fix "Container did not respond to SIGTERM within timeout" in Docker

  MEDIUM

• Exited (139) - Container terminated with SIGSEGV

  How to fix 'Exited (139)' SIGSEGV segmentation fault in Docker

  HIGH

• Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: connect: no such file or directory

  How to fix 'docker.sock: no such file or directory' in Docker

  MEDIUM

• Exited (137) - Container was killed by SIGKILL

  How to fix 'Exited (137)' container killed by SIGKILL in Docker

  MEDIUM

• WSL 2 requires an update to its kernel component

  How to fix 'WSL 2 requires an update to its kernel component' in Docker

  MEDIUM

• dial tcp: i/o timeout

  How to fix 'dial tcp: i/o timeout' in Docker

  MEDIUM

Official resources & further reading

• 📚Docker Official Documentation
• 📖
  Docker Docs: docker container stop(Official Docs)
• 📖
  Docker Docs: docker container kill(Official Docs)
• 📖
  Docker Docs: Resource constraints(Official Docs)
• 🐙
  GitHub: Why docker sends SIGKILL after 10 seconds(GitHub)
• 📝
  Komodor: SIGKILL Fast Termination of Linux Containers
• 📝
  Why Your Dockerized Application Isn't Receiving Signals
• 📝
  Medium: Trapping signals in Docker containers
• 📝
  Dev.to: 100 Common Docker Errors & Solutions