Docker Containers Not Starting on Boot? Fix Restart Policies

Last week, I rebooted a physical Red Hat Enterprise Linux 8 server after applying security updates that included a new kernel. The reboot itself completed normally, but there was one unexpected result: none of the Docker containers came back online.

This was a DEV server running Docker Engine with several containers. I expected the applications to return automatically after the host reboot, but every container remained stopped until I started them manually.

The problem was not the kernel update or Docker itself. The containers had been created without a restart policy, so Docker had no instruction to start them again when the daemon returned.

In this article, I will show how to verify the Docker service startup configuration, inspect the restart policy of existing containers, configure the appropriate policy, and distinguish a missing restart policy from a container that is actually failing during startup.

The root cause: Docker restart policies

Docker does not start containers automatically unless you tell it to. Whether a container comes back after a reboot is controlled by its restart policy – a setting attached to each container.

The restart policy has four possible values:

• no – the container is not restarted automatically. This is the default.
• on-failure[:max-retries] – restarts the container when it exits with a non-zero exit code. It does not restart the container simply because the Docker daemon restarts.
• always – restarts the container whenever it stops. If you stop it manually, Docker does not restart it immediately, but it will start again when the Docker daemon restarts.
• unless-stopped – similar to always, except that a container you intentionally stopped remains stopped even after the Docker daemon restarts.

For a server that needs its containers up after a reboot, unless-stopped is usually the right choice. It starts the container on boot, but respects a manual docker stop – so a container you stopped on purpose stays stopped.

Restart Policy Does Not Fix a Container That Cannot Start

A restart policy controls what Docker should do after a container stops or when the Docker daemon starts. It does not fix an application that fails during startup.

Docker only begins monitoring a restart policy after the container has started successfully and remained running for at least approximately 10 seconds.

If a container still does not stay running after the restart policy is configured, check its status and logs:

docker ps -a

docker logs <container-name>

Also inspect the exit status:

docker inspect <container-name> \
  --format 'ExitCode={{.State.ExitCode}} Error={{.State.Error}}'

Step 1 — Make Sure Docker Starts on Boot

Before checking individual containers, confirm that the Docker daemon itself is configured to start when the server boots.

systemctl is-enabled docker
systemctl enable --now docker

If the daemon itself is not enabled, containers will never come up after a reboot, regardless of their restart policy.

Step 2 — Check the current restart policy of a container

To see what a single container is configured to do, run:

docker inspect <container-name> --format '{{.HostConfig.RestartPolicy.Name}}'

If the output is no, that explains why the container didn’t come back automatically – it has the default policy and Docker will not start it.

To check the restart policy of all containers at once (running and not running containers):

for c in $(docker ps -aq); do docker inspect $c --format '{{.Name}} => {{.HostConfig.RestartPolicy.Name}}'; done

Step 3 — Set the restart policy

There are two ways, depending on whether the container already exists.

For a container that already exists, use docker update:

docker update --restart unless-stopped <container-name>

Note: Replace <container-name> with the actual container name.

For a new container, add --restart at creation time:

docker run -d --name my-app --restart unless-stopped my-image

Notes:

• Replace “my-app” to your container name.
• Replace “my-image” with the Docker image used by your application.

If the container is managed with Docker Compose, define the restart policy in the Compose file rather than changing only the running container manually:

services:
  my-app:
    image: my-image
    restart: unless-stopped

Apply the configuration:

docker compose up -d

If the service configuration changed, Compose can recreate the affected container to apply the new definition while preserving mounted volumes.

always vs unless-stopped: why it matters

This is the detail that confuses people. Both always and unless-stopped start the container when the Docker daemon starts. The difference is what happens when you manually stop a container:

• With always, if you run docker stop my-app and then reboot the server, Docker starts my-app again – even though you stopped it on purpose. On a DEV server where you often stop containers manually to test something, this can be annoying.
• With unless-stopped, a manually stopped container stays stopped after a reboot. It only auto-starts if it was running when the daemon stopped.

For most cases – and for my DEV server – unless-stopped is the better default. The full list of policies is documented in the Docker docs on starting containers automatically.

Verify the Restart Policy

First confirm the configured policy:

docker inspect <container-name> \
  --format '{{.HostConfig.RestartPolicy.Name}}'

Expected output:

unless-stopped

You can also check all containers:

for c in $(docker ps -aq); do
    docker inspect "$c" \
      --format '{{.Name}} => {{.HostConfig.RestartPolicy.Name}}'
done

At this point, the restart policy is configured.

If you want to perform an end-to-end validation, test it during a maintenance window by rebooting the host or restarting the Docker daemon. Keep in mind that restarting Docker can interrupt containers running on that server.

For example:

sudo systemctl restart docker

Then verify:

docker ps

Containers configured with always or eligible unless-stopped containers should return when the Docker daemon starts.

Note: Do not restart the Docker service on a production server solely to test this setting unless the impact on the running containers is understood.

What I Learned

The mistake in my environment was assuming that Docker would automatically bring every container back after the server rebooted. Restart behavior is opt-in and is configured per container.

After identifying the problem, I configured unless-stopped for the containers on this DEV server because it matches the way I use the environment: containers that were running should return after a host reboot, while containers that I intentionally stopped should remain stopped.

The important lesson is to verify both layers before the next maintenance reboot: make sure the Docker daemon starts with the operating system and make sure each application has the restart behavior that its workload actually requires.

External References