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

DockerBEGINNERLOWUpdated Dec 1, 2025· 238 views

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.

Quick fix

Fixes 143

# These commands send SIGTERM and result in exit 143
docker stop <container>
docker-compose down
kubectl delete pod <pod>
kubectl rollout restart deployment/<name>
  1. Verify if exit code 143 is expected behavior
  2. Check container logs for shutdown context
  3. Ensure your application handles SIGTERM properly
  4. Verify PID 1 signal handling in container
docker — error
# These commands send SIGTERM and result in exit 143
docker stop <container>
docker-compose down
kubectl delete pod <pod>
kubectl rollout restart deployment/<name>
Container exited with code 143 (SIGTERM)

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.

Typical symptoms

  • Container exits with status code 143 after docker stop command
  • Kubernetes pods show Terminated with exit code 143 during scaling or updates
  • Container logs show graceful shutdown messages before exit
  • Exit code 143 appears during CI/CD pipeline container cleanup
  • Docker Compose services exit with code 143 on docker-compose down
  • Containers exit with 143 during node draining or cluster maintenance

Common causes

  1. Manual docker stop command or docker-compose down (most common - expected behavior)
  2. Kubernetes terminating pods during deployments, scaling operations, or resource constraints
  3. Orchestrator moving containers to different nodes during cluster rebalancing
  4. Process manager or init system sending SIGTERM during system shutdown
  5. Health check failures causing orchestrator to replace the container
  6. Resource limits (memory/CPU) causing Kubernetes to evict the pod
  7. Manual kill -15 or kill -SIGTERM command sent to the process

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:

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

Advanced notes

Exit code 143 differs significantly from 137 (SIGKILL): while 143 indicates graceful termination, 137 means the process was forcefully killed, often due to timeout or OOM. In production, seeing 143 is generally positive - it means your application responded to the shutdown signal. However, if the shutdown takes too long (approaching the grace period), the orchestrator will escalate to SIGKILL.

Some applications use custom stop signals. For example, nginx and php-fpm use SIGQUIT for graceful shutdown instead of SIGTERM. You can configure this in your Dockerfile with STOPSIGNAL SIGQUIT or via docker run with --stop-signal=SIGQUIT.

In Kubernetes, the termination sequence is: preStop hook (if defined) -> SIGTERM -> wait terminationGracePeriodSeconds -> SIGKILL. Understanding this sequence helps debug shutdown issues. For long-running connections (WebSockets, database connections), implement connection draining in your preStop hook to allow in-flight requests to complete.

When running multiple processes in a container (not recommended but sometimes necessary), only PID 1 receives signals. Use a process manager like supervisord configured to forward signals, or redesign with multiple containers.

Frequently asked questions

What does "143" mean?
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.
How do I fix "143"?
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 causes "143"?
Manual docker stop command or docker-compose down (most common - expected behavior) Kubernetes terminating pods during deployments, scaling operations, or resource constraints Orchestrator moving containers to different nodes during cluster rebalancing
Is the "143" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading