19.3.4.1 Info Daemon Summary
A focused guide to Info Daemon Summary, connecting core concepts with practical Docker and container operations.
The daemon summary section of docker info output covers the configuration and operational state of the Docker daemon (dockerd) itself. It describes how the daemon is configured to store data, which runtime it uses, what default behaviors it applies to new containers, and how it interacts with the host operating system. This information is distinct from the container or image counts — it focuses on the daemon's own settings and capabilities.
Accessing the Daemon Summary
docker info
The daemon-level fields are embedded throughout the docker info output. There is no distinct "daemon section" header; the daemon configuration fields are interleaved with host information.
Server Version
Server Version: 25.0.3
The version of the Docker Engine daemon binary. This is the same value shown in docker version under the Server Engine section. It identifies the release of the daemon that is currently running.
Storage Driver
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
The storage driver is the component responsible for managing container and image filesystem layers.
- overlay2: The default and recommended driver for modern Linux kernels. It uses the kernel's overlay filesystem to efficiently stack image layers.
- Backing Filesystem: The type of filesystem on which the Docker root directory sits.
extfsis ext4;xfsis also commonly used. Not all filesystems support all storage drivers. - Supports d_type: The
d_typefield in directory entries is required for overlay2 to function correctly. Iffalse, Docker will refuse to use overlay2 on that filesystem. - Using metacopy: A Linux kernel feature that reduces unnecessary copies when an upper layer modifies metadata without touching file content.
falsemeans the feature is not in use. - Native Overlay Diff: When
true, the kernel's native diff computation is used rather than a slower fallback. - userxattr: Whether user-namespace extended attributes are used (relevant for rootless mode).
Logging Driver
Logging Driver: json-file
The default logging driver applied to all containers that do not specify a logging driver explicitly. Logs from container stdout and stderr are captured by this driver.
json-file: Writes logs to JSON files on the host at/var/lib/docker/containers/<id>/<id>-json.log. Supportsdocker logs.journald: Sends logs to systemd's journal.syslog: Sends logs to the system syslog daemon.none: Disables logging entirely for containers.awslogs,fluentd,splunk, etc.: Third-party drivers that forward logs to external systems.
Cgroup Driver and Version
Cgroup Driver: systemd
Cgroup Version: 2
cgroups (control groups) are the Linux kernel mechanism that enforces resource limits on container processes.
- Cgroup Driver:
systemdintegrates with systemd's cgroup management.cgroupfsmanages cgroups directly via the filesystem. On modern Linux distributions with systemd, thesystemddriver is recommended because it prevents hierarchy conflicts. - Cgroup Version:
2(unified hierarchy) is the current standard, providing a single unified cgroup tree. Version1is the legacy split hierarchy with separate trees per subsystem. Cgroup v2 is required for features like memory swap limits, rootless mode, and certain Kubernetes features.
Runtimes and Default Runtime
Runtimes: runc io.containerd.runc.v2
Default Runtime: runc
The runtime is the component that creates and manages individual container processes. Docker supports multiple OCI-compliant runtimes:
runc: The reference OCI runtime. Used for standard containers.io.containerd.runc.v2: The containerd-managed runc shim.
Additional runtimes can be registered (such as kata-runtime for hardware-isolated containers or gVisor for user-space kernel containers).
The Default Runtime is the one applied to containers that do not specify a runtime explicitly with --runtime.
Init Binary
Init Binary: docker-init
The init process Docker injects as PID 1 in containers started with --init. When enabled, docker-init handles signal forwarding and zombie process reaping. Without an init process, PID 1 is the application itself, which may not handle these responsibilities correctly if it spawns child processes.
containerd and runc Versions
containerd version: 7c3aca7a610df76212171d200ca3811ff6096eb8
runc version: v1.1.12-0-g51d5e946
init version: de40ad0
These are the versions of the container runtime subsystems bundled with or used by this Docker installation. They are the same values shown in docker version under the Server section.
Debug Mode
Debug Mode: false
When true, the daemon logs additional diagnostic information. Debug mode is enabled by starting the daemon with --debug or by setting "debug": true in /etc/docker/daemon.json. It increases log verbosity significantly and is typically only enabled during troubleshooting.
Docker Root Dir
Docker Root Dir: /var/lib/docker
The filesystem path where the daemon stores all its persistent data: image layers, container writable layers, volumes, build cache, and network configuration files. This directory can be changed in the daemon configuration with the data-root option.
Live Restore
Live Restore Enabled: false
When true, Docker configures the daemon to keep containers running even when the daemon is stopped or restarted. This is useful for production environments where rolling daemon upgrades must not interrupt running services. When false (the default), stopping the daemon stops all running containers.
Experimental
Experimental: false
Whether experimental Docker features are enabled on this daemon. Experimental features may be unstable and subject to change or removal.
Extracting Daemon Summary Fields
docker info --format "{{.Driver}}"
docker info --format "{{.LoggingDriver}}"
docker info --format "{{.CgroupDriver}}"
docker info --format "{{.CgroupVersion}}"
docker info --format "{{.DockerRootDir}}"
docker info --format "{{.LiveRestoreEnabled}}"
These queries are useful in configuration audits, CI scripts that require specific daemon settings, and diagnostic automation.