As a Senior DevOps Engineer, addressing “Docker CrashLoopBackOff” on Ubuntu 22.04 requires a systematic approach. This guide provides direct steps to diagnose and resolve this common container state.

---

Troubleshooting “Docker CrashLoopBackOff” on Ubuntu 22.04

1. The Root Cause “Docker CrashLoopBackOff” on Ubuntu 22.04 typically signifies that a container is repeatedly exiting shortly after startup. This often stems from application-level errors within the container, incorrect entrypoint configurations, or transient resource exhaustion, sometimes compounded by an unstable Docker daemon state or filesystem issues on the host.

2. Quick Fix (CLI) These commands help identify the immediate cause and attempt to stabilize the Docker environment.

# 1. Inspect recent container exits to identify the problematic one
# Look for containers with high 'RESTARTS' count or 'Exited' status.
echo "Listing recently exited containers:"
docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Ports}}\t{{.Image}}" | grep "Exited" || docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Ports}}\t{{.Image}}"

# 2. Get detailed logs from the suspected crashing container
# Replace <CONTAINER_ID_OR_NAME> with the actual ID or name of the problematic container.
echo "Fetching logs for the problematic container:"
docker logs <CONTAINER_ID_OR_NAME> --tail 100
docker inspect <CONTAINER_ID_OR_NAME> | grep -i 'error\|state\|exitcode' -A 5 -B 5

# 3. Attempt to clear transient Docker daemon issues by restarting the service
echo "Restarting Docker daemon..."
sudo systemctl restart docker
sudo systemctl status docker --no-pager # Verify Docker daemon is running

# 4. After Docker restarts, attempt to re-launch your service/container
echo "Attempting to re-launch the container/service..."
# If using a single container:
docker start <CONTAINER_ID_OR_NAME>
# If using Docker Compose (navigate to your docker-compose.yml directory first):
# cd /path/to/your/docker-compose/project
# docker-compose up -d

3. Configuration Check If the quick fix does not resolve the issue, review and modify the Docker daemon’s configuration for improved stability and diagnostics.

File to edit: /etc/docker/daemon.json

Action: Create or edit this file to enhance logging, ensure adequate storage, and set appropriate system resource limits. If creating, ensure it’s valid JSON.

sudo nano /etc/docker/daemon.json

Content to add/modify:

{
  "log-level": "debug",
  "data-root": "/var/lib/docker",
  "default-ulimits": {
    "nofile": {
      "Hard": 65536,
      "Soft": 65536
    }
  }
}

Explanation of changes:

• "log-level": "debug": Increases the verbosity of the Docker daemon’s logs. This is critical for identifying deeper issues that might not be apparent in container-specific logs. Revert to "info" after troubleshooting to reduce log volume.
• "data-root": "/var/lib/docker": Explicitly sets Docker’s storage root. Verify this path has ample disk space (df -h /var/lib/docker) and good I/O performance, as an overburdened or full disk can cause container startup failures.
• "default-ulimits": {...}: Sets higher default open file limits (nofile) for all new containers. Many applications, especially databases or web servers, can crash due to hitting the default lower limit of open files.

After modifying daemon.json, restart the Docker daemon for changes to take effect:

sudo systemctl restart docker

4. Verification Confirm that the Docker daemon is stable and your containers are running as expected.

# 1. Verify Docker daemon is running without errors
sudo systemctl status docker --no-pager

# 2. Check the status of your container(s)
# For a specific container:
docker ps -a | grep <CONTAINER_ID_OR_NAME>
# Look for 'Up' status.

# For a Docker Compose project (navigate to the directory first):
# cd /path/to/your/docker-compose/project
docker-compose ps

# 3. Check logs of the previously crashing container for successful startup messages
docker logs <CONTAINER_ID_OR_NAME> --tail 50