<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Docker Engine on Netdata</title><link>https://www.netdata.cloud/tags/docker-engine/</link><description>Recent content in Docker Engine on Netdata</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://www.netdata.cloud/tags/docker-engine/index.xml" rel="self" type="application/rss+xml"/><item><title>Docker commands hang: docker ps, inspect, and exec freezes</title><link>https://www.netdata.cloud/guides/docker/docker-commands-hang/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-commands-hang/</guid><description>&lt;p&gt;&lt;code&gt;docker ps&lt;/code&gt;, &lt;code&gt;docker inspect&lt;/code&gt;, and &lt;code&gt;docker exec&lt;/code&gt; hang while containers continue serving traffic. This is a Docker daemon hang: the management plane is dead while the data plane survives. Standard process monitors show &lt;code&gt;dockerd&lt;/code&gt; as alive, yet you cannot manage, inspect, or evacuate workloads.&lt;/p&gt;&#10;&lt;p&gt;This guide covers how to distinguish a hang from a crash, identify whether the root cause is storage, a stuck shim, a plugin, or an internal deadlock, and recover without unnecessary host reboots or container kills.&lt;/p&gt;</description></item><item><title>Docker disk space full: how to troubleshoot /var/lib/docker</title><link>https://www.netdata.cloud/guides/docker/docker-disk-space-full/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-disk-space-full/</guid><description>&lt;p&gt;You notice deployments failing with &amp;ldquo;no space left on device,&amp;rdquo; image pulls hanging, or the Docker daemon becoming sluggish. On a &lt;a href="https://www.netdata.cloud/guides/docker/"&gt;Docker&lt;/a&gt; host, everything lives under /var/lib/docker: image layers, container writable layers and logs, named volumes, and build cache. When this filesystem fills, the failure is cascading and abrupt. New containers cannot start, running containers may fail on writes, and daemon operations deadlock.&lt;/p&gt;&#10;&lt;p&gt;This guide walks through identifying which of the five major consumers is dominating your disk, safely reclaiming space without deleting data you still need, and fixing the configuration gaps that let it happen again.&lt;/p&gt;</description></item><item><title>Docker image pull failures: registry, network, and auth diagnosis</title><link>https://www.netdata.cloud/guides/docker/docker-image-pull-failures/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-image-pull-failures/</guid><description>&lt;h2 id="what-this-means"&gt;What This Means&lt;/h2&gt;&#10;&lt;p&gt;When you run &lt;code&gt;docker pull&lt;/code&gt;, the daemon negotiates a TLS connection to the registry, authenticates if required, resolves the manifest for the requested tag and architecture, then downloads missing layers. If any step fails, the pull aborts.&lt;/p&gt;&#10;&lt;p&gt;Registry errors surface as HTTP 429 or 401/403 responses. Network errors appear as timeouts, connection resets, or TLS handshake failures. Local problems such as a full disk or a hung daemon can also abort a pull even when the registry is healthy. In orchestrated environments, a single node&amp;rsquo;s pull failure can trigger the scheduler to retry on other nodes, turning a localized auth error into a cluster-wide rate limit storm. Distinguishing these layers quickly is the difference between a five-minute fix and a prolonged outage.&lt;/p&gt;</description></item><item><title>Docker log rotation: preventing json-file logs from filling disk</title><link>https://www.netdata.cloud/guides/docker/docker-log-rotation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-log-rotation/</guid><description>&lt;p&gt;Docker&amp;rsquo;s default &lt;code&gt;json-file&lt;/code&gt; log driver appends every line of container stdout and stderr to a JSON file on the host under &lt;code&gt;/var/lib/docker/containers/&amp;lt;id&amp;gt;/&lt;/code&gt;. Without size limits, that file grows monotonically. A single verbose container can consume tens of gigabytes, and because the driver is the default, this often happens silently until &lt;code&gt;/var/lib/docker&lt;/code&gt; fills. At that point image pulls fail, container creates are rejected, and the daemon may hang on storage operations. This guide covers how to cap log files with &lt;code&gt;daemon.json&lt;/code&gt; and per-container &lt;code&gt;log-opt&lt;/code&gt; overrides, verify the caps are working, and choose a different driver when json-file is not appropriate.&lt;/p&gt;</description></item><item><title>Docker Monitoring</title><link>https://www.netdata.cloud/monitoring-101/docker-monitoring/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/monitoring-101/docker-monitoring/</guid><description>&lt;h2 id="docker-monitoring"&gt;Docker Monitoring&lt;/h2&gt;&#10;&lt;h3 id="what-is-docker"&gt;What Is Docker?&lt;/h3&gt;&#10;&lt;p&gt;Docker is an open platform that packages applications and their dependencies into lightweight, portable units called &lt;strong&gt;containers&lt;/strong&gt;. A container bundles everything the software needs to run — code, runtime, system tools, libraries, and settings — so it behaves the same way on a developer&amp;rsquo;s laptop, in staging, and in production. Because containers share the host operating system&amp;rsquo;s kernel instead of shipping a full guest OS, they start in milliseconds and use far fewer resources than virtual machines.&lt;/p&gt;</description></item><item><title>Docker monitoring checklist: the signals every production host needs</title><link>https://www.netdata.cloud/guides/docker/docker-monitoring-checklist/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-monitoring-checklist/</guid><description>&lt;p&gt;Production Docker incidents rarely look like Docker problems at first. They show up as application latency, deployment failures, or hosts that suddenly refuse to schedule containers. By the time you notice, the daemon may be hung, a log file has filled the disk, or a container has been silently throttled into unusable latency. This checklist groups the essential production signals into three priority tiers: must-have alerts that keep the host alive, should-have metrics that expose resource pressure before it becomes an outage, and nice-to-have security and internal signals for mature environments. Every signal includes where to read it from the raw cgroup filesystem or the Docker API so you can instrument hosts without guessing paths.&lt;/p&gt;</description></item><item><title>Docker Operations Guides</title><link>https://www.netdata.cloud/guides/docker/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/</guid><description>Learn how Docker actually runs in production, what breaks first, and what to monitor as your operation grows up.</description></item><item><title>Docker port binding: address already in use</title><link>https://www.netdata.cloud/guides/docker/docker-port-binding-address-already-in-use/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-port-binding-address-already-in-use/</guid><description>&lt;p&gt;A &lt;code&gt;docker run -p 8080:80&lt;/code&gt; or &lt;code&gt;docker compose up&lt;/code&gt; fails with &lt;code&gt;bind: address already in use&lt;/code&gt;. The error is clear, but the owner is not. &lt;code&gt;ss&lt;/code&gt; may show a system service. &lt;code&gt;docker ps&lt;/code&gt; may show nothing, yet Docker still refuses. The port can appear free while an orphaned DNAT rule or a split firewall backend blocks the bind.&lt;/p&gt;&#10;&lt;p&gt;Distinguish a genuine socket conflict from an orphaned DNAT rule, a rootless Docker regression, and a WSL2 iptables/nftables split brain. Then reclaim the port and prevent recurrence.&lt;/p&gt;</description></item><item><title>Docker published port not reachable: troubleshooting -p and EXPOSE</title><link>https://www.netdata.cloud/guides/docker/docker-published-port-not-reachable/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-published-port-not-reachable/</guid><description>&lt;p&gt;You mapped a port with &lt;code&gt;-p 8080:80&lt;/code&gt;, but &lt;code&gt;curl&lt;/code&gt; against the host IP returns connection refused. &lt;code&gt;docker ps&lt;/code&gt; shows the mapping, the container is running, and the port still appears closed.&lt;/p&gt;&#10;&lt;p&gt;A published port depends on three layers: a runtime mapping rule (&lt;code&gt;-p&lt;/code&gt;), a host forwarding path (iptables DNAT and FORWARD policy), and an application listener inside the container bound to an interface that receives the forwarded packet. EXPOSE in a Dockerfile is metadata. It does not publish ports, create firewall rules, or set bind addresses.&lt;/p&gt;</description></item><item><title>Docker socket security: why /var/run/docker.sock is root access</title><link>https://www.netdata.cloud/guides/docker/docker-socket-security/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-socket-security/</guid><description>&lt;p&gt;Mounting &lt;code&gt;/var/run/docker.sock&lt;/code&gt; into a container grants that container a root-equivalent privilege boundary. This is not a Docker vulnerability. The daemon runs as root, listens on a filesystem socket, and trusts any client that can write to it.&lt;/p&gt;&#10;&lt;p&gt;Symptoms of abuse look like container escape or host compromise, but the container never escaped. It asked the root-owned daemon to perform privileged operations on its behalf. This guide explains the mechanism, how to audit exposure, and what constraints you can apply without rebuilding your pipeline.&lt;/p&gt;</description></item><item><title>Reading docker system df: where Docker disk usage actually lives</title><link>https://www.netdata.cloud/guides/docker/docker-system-df/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-system-df/</guid><description>&lt;p&gt;You run &lt;code&gt;docker system df&lt;/code&gt; but the numbers do not add up to what &lt;code&gt;df -h&lt;/code&gt; reports. Maybe the Build Cache row is empty while &lt;code&gt;/var/lib/docker/buildkit/&lt;/code&gt; consumes tens of gigabytes. Maybe RECLAIMABLE is high but &lt;code&gt;docker system prune&lt;/code&gt; barely frees space because overlay2 layer sharing masks the real unique cost. Or the daemon returns &lt;code&gt;Error response from daemon&lt;/code&gt; when the disk is already full. This guide shows how to read &lt;code&gt;docker system df&lt;/code&gt; precisely, what it hides, and how to triage the real consumers on the host.&lt;/p&gt;</description></item></channel></rss>