Which daemon.json changes take effect on a Docker daemon reload, and which need a restart?

## Two different operations There are two ways to make `dockerd` look at `/etc/docker/daemon.json` again, and they differ in both scope and blast radius. **Reload** is `systemctl reload docker`, which sends the daemon a SIGHUP (you can send it directly with `kill -HUP $(pidof dockerd)`). The daemon stays up, re-reads the configuration file, and applies the subset of settings that it knows how to change in a live process. No container is touched: the engine keeps serving the API throughout and the workloads never notice. **Restart** is `systemctl restart docker`, which stops the daemon process and starts a new one. Everything in the file is read fresh, because the new process is configuring itself from scratch. That is the expensive option: without `live-restore`, stopping the daemon stops the containers it supervises, and when it comes back it starts the ones whose restart policy is `always` or `unless-stopped`. Containers created with `--restart no` stay stopped until someone starts them. ## What reloads The reloadable set is deliberately small — it is the settings the daemon can swap out without rebuilding its own state. In practice it covers: - `debug` and `log-level` — turning daemon debugging on during an incident and off afterwards is the classic use of a reload. - `registry-mirrors` and `insecure-registries` — the daemon's registry client configuration is re-created. - `live-restore` — you can enable it on a live daemon, which matters because it is the setting that makes the *next* restart cheap. - `labels` — engine labels that a scheduler may select on. - `max-concurrent-downloads` and `max-concurrent-uploads` — pull/push parallelism. - `runtimes` and `default-runtime` — registering an alternative OCI runtime. - `shutdown-timeout` — how long the daemon waits for containers on the way down. ## What does not Anything the daemon builds its world on top of is start-up only: - `storage-driver` — the driver is initialised once, against `data-root`, when the daemon starts. - `data-root` — the entire on-disk layout is opened at start-up. - `hosts` — the sockets and addresses the API listens on are bound at start-up. - The bridge networking options (`bip`, the default bridge's address, `iptables`) — the daemon programs the host's networking as it comes up. A reload does not fail loudly on these; the daemon simply keeps running with what it has. That is a classic trap: someone edits `data-root`, runs `systemctl reload docker`, sees no error, and concludes the change is live. `docker info` still prints the old Docker Root Dir, which is the honest answer. ## Reload is not retroactive over containers Even for a key that reloads, the effect is on the daemon, not on containers that already exist. A container's effective configuration — its logging setup, its resource limits, its network attachments — is fixed when it is created. So changing a host-wide default and reloading changes the defaults handed to containers created from that point on. Existing containers must be recreated to pick it up. Restarting a container does not recreate it. ## live-restore, and why it belongs in this conversation `"live-restore": true` tells the daemon to leave running containers alive when it exits, and to re-attach to them when it starts again. It is what turns a daemon restart from an outage into a blip, and it is why an engine upgrade on a busy host is survivable. It has real limits: it does not apply to a host that has joined a swarm, it is intended for patch-level engine upgrades rather than arbitrary version jumps, and while the daemon is down nobody is reading the containers' output — once the buffer between a container and the absent daemon fills, the container's writes block until the daemon returns. `docker logs`, `docker events` and health-check evaluation are also unavailable for the duration. Enabling live-restore is itself reloadable, but it only protects restarts that happen *after* it is on. ## How to check what happened Three habits make this concrete. First, `dockerd --validate` before you apply anything, so a syntax error never reaches a live daemon. Second, `docker info` afterwards, because it prints what the daemon actually adopted rather than what you wrote. Third, the daemon's journal — `journalctl -u docker --since '5 min ago'` — which records the reload and any setting it refused. If you cannot tell from those three whether a change is live, assume it is not. ## The interview shape The question is usually posed as "you changed X, is a restart needed?", and the answer they are listening for is not a memorised list but the principle: settings that the daemon can hand to new work reload, settings that define the daemon's own storage, sockets and networking do not — and a restart is a container-visible event unless live-restore is on.