DevOps PeachLive restore
By default, when the Docker daemon (dockerd) stops, every running container stops with it. Live restore keeps containers running while the daemon crashes, is under maintenance or is upgraded, and the daemon "reattaches" them when it comes back.
{ "live-restore": true }
Add it to /etc/docker/daemon.json, then reload (not restart) to apply it without stopping containers:
sudo systemctl reload docker
docker info --format '{{.LiveRestoreEnabled}}' # true
Live restore does not help when the whole machine reboots: containers stop with the machine; to bring them back automatically, use a restart policy (--restart unless-stopped).
flowchart LR
D["dockerd stops / is upgraded"] --> Q{"live-restore?"}
Q -- "false" --> S["Containers stop too"]
Q -- "true" --> R["Containers keep running; daemon reattaches them"]
Several processes in one container
The main process of a container is its ENTRYPOINT/CMD; the container lives as long as that process does. Recommendation: one service per container, for example web and database as two containers.
If you really must run several processes:
| Approach | Note |
|---|---|
| A wrapper script as CMD | The script must watch the processes and exit when one dies, otherwise the container stays "Up" with a dead service |
Bash job control (set -m, background then fg %1) |
Simple; fits one main process plus one helper |
A process manager such as supervisord |
Watches and restarts each process, but makes the image heavier |
Restart policies
| Policy | Restarts when | After daemon or host restart |
|---|---|---|
no (default) |
Never | Stays stopped |
on-failure[:5] |
Exit code is not 0, optionally up to N times | Restarted if it had been running |
always |
Any exit | Restarted, even if you stopped it by hand before |
unless-stopped |
Any exit | Restarted, unless you stopped it by hand |
Live restore keeps containers alive while the daemon is down; restart policies bring them back after they or the host stop. They solve different problems and are often used together on single hosts. Live restore is not compatible with Swarm mode, where the swarm itself reschedules tasks.
Health is not enough by itself
A HEALTHCHECK marks a container unhealthy, but plain Docker does not restart it for that reason; only an exit triggers a restart policy. Swarm services and Kubernetes do replace unhealthy containers. On a single host, either make the app exit when it is broken or use a small watchdog.
Alternatives to many processes
| Pattern | Idea |
|---|---|
| Separate containers | Web server and worker as two services in one Compose file |
| Sidecar | A helper container, such as a log shipper, sharing a volume or network namespace with the app |
| Init container step | A one-off container that runs migrations before the app starts |
s6-overlay |
A lightweight init and supervisor designed for containers, when several processes are unavoidable |
Separate containers can be scaled, restarted, updated, and monitored independently, and each has a clear log stream.
Planning daemon upgrades
Even with live restore, upgrades that skip versions may not reattach containers, and the daemon must be stopped carefully (systemctl reload for config, a maintenance window for upgrades). On important hosts, drain the workload to another host first or schedule the upgrade with restart policies in place.