Docker’s "live-restore" feature is often misunderstood as a magic bullet for keeping containers always up, but its real power is in how it gracefully handles daemon restarts, preventing abrupt container termination and allowing for a much smoother recovery.
Let’s see it in action. Imagine you have a simple Nginx container running:
docker run -d --name my-nginx nginx
Now, to simulate a daemon restart, we’ll gracefully stop and then start the Docker daemon. On most Linux systems, this looks like:
sudo systemctl stop docker
# ... wait a few seconds ...
sudo systemctl start docker
If live-restore is not enabled, docker stop docker would typically kill running containers. However, if live-restore is enabled, the containers will remain running, and the daemon will re-establish its connection to them upon restart.
To enable live-restore, you need to modify the Docker daemon’s configuration file, typically located at /etc/docker/daemon.json. You’ll add or modify the live-restore key:
{
"live-restore": true
}
After saving this file, you must restart the Docker daemon for the change to take effect:
sudo systemctl restart docker
Now, when you perform that sudo systemctl stop docker and sudo systemctl start docker sequence again, your my-nginx container will continue serving requests throughout the daemon’s downtime.
The core problem live-restore solves is the default behavior where a Docker daemon shutdown triggers a SIGKILL on all associated containers. This is because the daemon is the primary orchestrator, managing the container’s lifecycle and network interfaces. When it disappears, the containers are left orphaned and are consequently terminated to prevent potential resource leaks or inconsistent states. Live-restore changes this by instructing the daemon, upon its restart, to re-attach to existing containers that were running prior to its shutdown, rather than assuming they should be stopped. It essentially tells the daemon, "don’t kill what you can reconnect to."
The live-restore option acts as a flag during the daemon’s startup. When enabled, the daemon doesn’t immediately initiate a shutdown sequence for running containers when it detects it’s about to be stopped or crash. Instead, it marks these containers for re-attachment. When the daemon comes back online, it scans for containers that were in a running state before its shutdown and re-establishes its control over them. This involves re-associating the container’s namespaces, network connections, and its cgroup with the re-started daemon process.
The most surprising aspect of live-restore is how it interacts with container restarts versus daemon restarts. While it’s designed for daemon restarts, it doesn’t prevent individual container restarts from terminating and recreating containers. If you manually run docker restart my-nginx while live-restore is enabled, the container will still stop and start anew, as this is an explicit user command to kill and recreate the container process, not an unexpected daemon interruption.
The next logical step after ensuring your daemon can survive restarts is to explore how to manage persistent storage for these containers, ensuring that even if a container does need to be recreated, its data remains intact.