2.1.1 Daemon Role

The daemon role describes what dockerd, the Docker daemon, is actually responsible for within Docker's overall architecture: it is the long-running background process that does the real work behind every Docker command, managing images, containers, networks, and volumes on behalf of whatever client requests them.

The Daemon as the Actual Worker

When the docker CLI is used to build an image or start a container, the CLI itself does none of that work directly — it sends a request to the daemon, which performs the actual operation and reports the result back.

docker run -d nginx

The daemon receives this request, pulls the nginx image if it is not already present locally, creates the container, and starts it — all of this work happens inside the daemon process, not inside the docker command itself.

Running as a System Service

The daemon typically runs as a system service, started automatically when the host boots, so it is available to handle requests at any time without a user needing to start it manually.

systemctl status docker
systemctl restart docker

Restarting the daemon affects every container it manages, which is why daemon restarts are usually planned carefully on hosts running important workloads.

Managing State Across Restarts

The daemon maintains the authoritative state of what containers, images, networks, and volumes exist on its host, persisting this information so that the same containers are recognized as existing even after the daemon process itself restarts.

docker ps -a

This reflects the daemon's own record of containers, including ones that are stopped, not running processes that the CLI happens to be aware of independently.

Logging the Daemon's Own Activity

Because the daemon is a separate process from any individual container, its own logs are distinct from container logs and are useful when diagnosing problems that occur before a container even starts.

journalctl -u docker.service -f

Why the Daemon's Role Matters for Troubleshooting

When something fails in a way that suggests Docker itself rather than a specific container is the problem — commands hanging, containers failing to start at all — the daemon, not any individual container, is the right place to look first, since it is the single component responsible for actually carrying out every Docker operation on its host.