19.3.4.3 Info Runtime Details

The runtime details in docker info describe which container runtimes are available on the Docker host and which one is used by default. A container runtime is the software layer responsible for creating and running containers using operating system primitives such as namespaces, cgroups, and seccomp filters. Docker supports plugging in different runtimes, which allows for flexibility in isolation models, security levels, and compatibility requirements.

Runtime Information in docker info Output

docker info

Runtimes: runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: docker-init
containerd version: 7c3aca7a610df76212171d200ca3811ff6096eb8
runc version: v1.1.12-0-g51d5e946
init version: de40ad0

Runtimes Field

Runtimes: runc io.containerd.runc.v2

This lists all container runtimes registered with the Docker daemon. Each name is the identifier used when specifying --runtime on docker run or docker create.

runc

runc is the reference implementation of the OCI (Open Container Initiative) Runtime Specification. It is the standard low-level runtime that creates containers using Linux kernel features:

• Namespaces: PID, network, mount, UTS, IPC, user, and cgroup namespaces isolate container processes from the host and from each other.
• Cgroups: Enforce resource limits (CPU, memory, I/O, network) on container processes.
• Seccomp: System call filtering that restricts which kernel calls container processes can make.
• Capabilities: Drops most Linux capabilities from container processes, reducing the attack surface.
• Mandatory Access Control: Applies AppArmor or SELinux policies to container processes where configured.

runc is a standalone binary that the containerd daemon invokes directly.

io.containerd.runc.v2

io.containerd.runc.v2 is the containerd shim for runc. It runs as an intermediary process (a "shim") between containerd and the actual runc process. The shim remains running after runc exits to hold the container's I/O streams and allow containerd to reconnect after a daemon restart.

Both runc and io.containerd.runc.v2 ultimately use the same runc binary for container creation. The shim-based approach provides better daemon restart resilience.

Additional Runtimes

Additional runtimes appear in this list when they have been registered in the Docker daemon configuration. Examples:

• kata-runtime: The Kata Containers runtime, which runs containers inside lightweight virtual machines rather than using kernel namespaces. Provides stronger isolation at the cost of higher startup latency.
• runsc: gVisor's runtime. Implements a user-space kernel that intercepts container system calls, providing an additional layer of isolation without a full virtual machine.
• crun: A C implementation of the OCI runtime spec, compatible with runc but lighter.

Registering additional runtimes:

{
  "runtimes": {
    "kata-runtime": {
      "path": "/usr/bin/kata-runtime"
    }
  }
}

After adding to /etc/docker/daemon.json and restarting the daemon, the new runtime appears in docker info.

Default Runtime

Default Runtime: runc

The default runtime is applied to all containers that do not specify a runtime explicitly at creation time. To start a container with a non-default runtime:

docker run --runtime kata-runtime my_image

To change the default runtime for all containers on the host, set it in /etc/docker/daemon.json:

{
  "default-runtime": "kata-runtime"
}

Init Binary

Init Binary: docker-init

The init binary is the process Docker injects as PID 1 in containers started with --init. Without an init process, the container's main process runs as PID 1 and is responsible for handling signals and reaping zombie processes. Many applications are not designed to run as PID 1 and do not handle these responsibilities.

docker-init is a minimal init system (based on tini) that:

• Forwards signals (SIGTERM, SIGINT, etc.) to the main process.
• Reaps zombie child processes to prevent PID namespace exhaustion.

To use the init binary:

docker run --init my_image

The Init Binary field shows the name of the binary Docker uses for this purpose.

containerd Version

containerd version: 7c3aca7a610df76212171d200ca3811ff6096eb8

containerd is the container runtime manager that sits between the Docker daemon and the low-level runtime (runc). It manages the full container lifecycle: image storage, container creation, start/stop, I/O attachment, and runtime supervision. The version shown is the containerd binary bundled with or installed alongside Docker Engine.

runc Version

runc version: v1.1.12-0-g51d5e946

The version of the runc binary. This is important for security assessments because container runtime vulnerabilities (such as container escapes) are typically discovered at the runc level. Keeping runc up to date is part of container security maintenance.

init Version

init version: de40ad0

The version of the docker-init binary, expressed as a short Git commit hash.

Runtime Isolation Comparison

The choice of runtime is a tradeoff between isolation level, performance, and application compatibility. Most workloads use the default runc runtime. Workloads with elevated security requirements, such as multi-tenant environments or untrusted code execution, may use Kata Containers or gVisor.