How to fix Container exited with code 143 (SIGTERM) in Docker

DockerBEGINNERLOW

Exit code 143 indicates that a Docker container received a SIGTERM signal and terminated gracefully. This is typically a normal shutdown behavior when stopping containers with docker stop, during orchestrator scaling, or when manually terminating processes.

What this error means

Exit code 143 is calculated as 128 + 15, where 15 is the signal number for SIGTERM (the standard Unix termination signal). When a container exits with code 143, it means the main process received a SIGTERM signal and shut down accordingly. This is generally considered a healthy shutdown - unlike exit code 137 (SIGKILL), which indicates a forced termination, exit code 143 shows that the container had the opportunity to perform cleanup operations before exiting. SIGTERM is a 'polite' termination request that gives processes a chance to gracefully shut down - closing database connections, completing in-flight requests, flushing logs, and releasing resources. When you run `docker stop`, Docker sends SIGTERM to the container's main process (PID 1) and waits for a configurable grace period (default 10 seconds) before escalating to SIGKILL if the process hasn't exited. In most cases, exit code 143 is not an error but expected behavior indicating your container properly handled the shutdown signal.

How to fix "Container exited with code 143 (SIGTERM)"

1Verify if exit code 143 is expected behavior

First, determine whether the SIGTERM was intentional. Exit code 143 after these operations is normal:

bash

# These commands send SIGTERM and result in exit 143
docker stop <container>
docker-compose down
kubectl delete pod <pod>
kubectl rollout restart deployment/<name>

Check if the exit coincides with deployments, scaling events, or manual intervention:

bash

# Check container exit details
docker inspect <container-id> --format='{{.State.ExitCode}} - {{.State.FinishedAt}}'

# For Kubernetes, check events
kubectl describe pod <pod-name> | grep -A 10 Events

If exit code 143 appears when you didn't expect a shutdown, continue investigating.

2Check container logs for shutdown context

Review the container logs to understand what happened before termination:

bash

# View recent logs including shutdown messages
docker logs --tail 100 <container-id>

# For Kubernetes, check previous container logs
kubectl logs <pod-name> --previous

Look for:
- Graceful shutdown messages (good sign)
- Error messages before shutdown
- Connection termination logs
- Resource cleanup confirmations

A healthy shutdown typically shows messages like 'Received SIGTERM, shutting down...' followed by cleanup logs.

3Ensure your application handles SIGTERM properly

If your application isn't handling SIGTERM, it may exit abruptly without cleanup. Implement signal handling:

Node.js:

javascript

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

Python:

python

import signal
import sys

def handle_sigterm(signum, frame):
    print('Received SIGTERM, cleaning up...')
    # Cleanup code here
    sys.exit(0)

signal.signal(signal.SIGTERM, handle_sigterm)

Go:

quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGTERM)
<-quit
// Graceful shutdown logic

4Verify PID 1 signal handling in container

Containers that run applications as PID 1 may not handle signals correctly by default. Use an init system:

Option 1: Docker's built-in init (recommended)

bash

docker run --init <image>

Or in docker-compose.yml:

yaml

services:
  app:
    init: true
    image: myapp

Option 2: Use tini in Dockerfile

dockerfile

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

Option 3: Use exec in shell entrypoints

bash

#!/bin/sh
# setup commands...
exec ./myapp  # Replace shell with app, so app receives signals

5Adjust termination grace period if needed

If your application needs more time to shut down gracefully, increase the timeout:

Docker:

bash

# Give container 60 seconds to shut down
docker stop --time=60 <container>

Docker Compose:

yaml

services:
  app:
    stop_grace_period: 60s

Kubernetes:

yaml

spec:
  terminationGracePeriodSeconds: 60
  containers:
  - name: app
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 5"]

The default is 10 seconds in Docker and 30 seconds in Kubernetes.

6Use exec form in Dockerfile for proper signal propagation

The shell form of CMD/ENTRYPOINT wraps your command in /bin/sh -c, which doesn't forward signals:

dockerfile

# BAD: Shell form - signals go to shell, not your app
CMD python app.py

# GOOD: Exec form - signals go directly to your app
CMD ["python", "app.py"]

Same applies to ENTRYPOINT:

dockerfile

# BAD: Shell form
ENTRYPOINT ./start.sh

# GOOD: Exec form
ENTRYPOINT ["./start.sh"]

Always use the JSON array (exec) form unless you specifically need shell features.

7Investigate unexpected SIGTERM sources in Kubernetes

If containers receive unexpected SIGTERM signals in Kubernetes, check for:

OOM evictions (memory pressure):

bash

kubectl describe pod <pod-name> | grep -i oom
kubectl top pod <pod-name>

Failed health checks:

bash

kubectl describe pod <pod-name> | grep -A 5 'Liveness\|Readiness'

Node issues:

bash

kubectl describe node <node-name> | grep -A 10 Conditions

Resource quota exceeded:

bash

kubectl describe quota -n <namespace>

Check cluster events for termination reasons:

bash

kubectl get events --sort-by='.lastTimestamp' | grep -i termin

How to fix Container exited with code 143 (SIGTERM) in Docker

What this error means

Typical symptoms

Common causes

How to fix "Container exited with code 143 (SIGTERM)"

Advanced notes

Related errors

Official resources & further reading