✦ For everyone, free.

Practical knowledge for real and everyday life

Home

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. extfs is ext4; xfs is also commonly used. Not all filesystems support all storage drivers.
  • Supports d_type: The d_type field in directory entries is required for overlay2 to function correctly. If false, 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. false means 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. Supports docker 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: systemd integrates with systemd's cgroup management. cgroupfs manages cgroups directly via the filesystem. On modern Linux distributions with systemd, the systemd driver is recommended because it prevents hierarchy conflicts.
  • Cgroup Version: 2 (unified hierarchy) is the current standard, providing a single unified cgroup tree. Version 1 is 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.