What happens to running containers when the Docker daemon (`dockerd`) itself is stopped, restarted or upgraded, and what does the daemon's `live-restore` option change about that?

## The default coupling On a stock Docker installation the daemon and the containers share a fate. `systemctl stop docker` (or an engine package upgrade that restarts the unit) causes the daemon to shut down its running containers — they receive the stop sequence and exit. For a single-host deployment that means every engine upgrade is a scheduled outage for every workload on the box. When the daemon starts again it performs a reconciliation pass over its container store and applies each container's restart policy: - `always` → started, even if it had been deliberately stopped before; - `unless-stopped` → started only if it was running when the daemon went away; - `on-failure` → containers that were running are brought back up; - `no` → left alone. This reconciliation is exactly why restart policies are persisted in the container's host config rather than held in memory, and it is the concrete reason `always` and `unless-stopped` differ at all. ## What the runtime stack actually looks like Understanding `live-restore` requires knowing that `dockerd` is not the container's parent process. The stack is: `dockerd` (API, images, networks, build) → `containerd` (container supervision) → a per-container shim → `runc`, which sets up namespaces and cgroups and then exits, leaving the container's PID 1 parented to the shim. Because the shim is what actually holds the container, the container process can survive `dockerd` exiting — the coupling in the default configuration is a *policy decision* by the daemon, not a technical necessity. ## Enabling live-restore Add to `/etc/docker/daemon.json`: ``` { "live-restore": true } ``` and reload the daemon. From then on, when `dockerd` stops, running containers stay running; when it comes back, it re-discovers them through containerd and re-attaches to their shims, log streams and state. Users see uninterrupted traffic through a daemon restart. ## The caveats that decide whether you can use it **Patch upgrades only.** The documented support boundary is patch-level daemon versions. Across a major or minor version change, on-disk state and shim interfaces can change enough that re-attachment isn't guaranteed, and the daemon may end up stopping the containers anyway. Plan minor/major engine upgrades as drains, not as live restores. **Not with Swarm mode.** A daemon participating in a swarm cannot use live-restore; swarm's own reconciliation loop assumes the daemon is authoritative and present. If a node's daemon disappears, the manager reschedules tasks elsewhere — which is the orchestrator solving the same problem a different way. **No supervision during the gap.** This is the point most candidates miss. While the daemon is down there is no API, no `docker` CLI, no health-check execution, no event stream, and crucially **no restart-policy enforcement**. If a container crashes during that window, nothing restarts it; it simply stays dead until the daemon returns and reconciles state. Live-restore keeps healthy containers alive; it does not extend supervision. **Log buffering.** Container stdout/stderr is written through a FIFO that the daemon normally drains into the logging driver. With the daemon absent, that buffer fills. A chatty container during a long daemon outage can block on writes — a subtle way an apparently "live-restored" workload stalls. **Config changes need care.** Some daemon-level changes (notably the default logging driver or bridge networking parameters) don't apply cleanly to containers restored from a previous daemon; you may find restored containers keeping old settings until they're recreated. ## Choosing the approach Single-host, uptime-sensitive services with routine patch upgrades: turn `live-restore` on and treat engine patching as a live operation, while still testing minor upgrades as drains. Multi-host with an orchestrator: don't bother — drain the node, let the orchestrator move workloads, upgrade, and bring the node back. Redundancy above the host is a stronger answer than surviving a daemon restart on one box. Either way, be explicit in an interview about the layering: `live-restore` addresses *daemon* availability; restart policies address *container* failure. They are different failure domains, and one does not cover the other. A container with `--restart=unless-stopped` on a `live-restore` host survives both a crash (policy restarts it) and a daemon patch upgrade (live-restore keeps it up) — but not a crash *during* the daemon upgrade, which is a small, real gap worth naming.