Q: During an outage of your centralized log aggregator (Fluentd / Splunk), several critical customer-facing microservices running in Docker completely froze and stopped accepting incoming HTTP requests. Application threads were stuck in `write()` syscalls to stdout/stderr. SREs were astonished that a failure in the logging aggregator could bring down business-critical production applications. You must explain the mechanics of Docker's logging pipe buffer, configure non-blocking logging, and size the ring buffer.

When a container starts, Docker redirects its stdout and stderr to Linux named pipes (FIFOs) managed by `containerd-shim`. In default `blocking` mode, if the logging driver cannot consume logs fast enough, the 64KB kernel pipe buffer fills up, causing application `write()` system calls to block indefinitely.

<!-- Logging Pipe Deadlock Flow -->
Application (writes to stdout) ───> Linux Kernel FIFO Pipe (64KB Buffer)
                                              │ (Buffer FULL!)
                                              └───> write() syscall BLOCKS!
                                              └───> Application Threads Freeze!
Logging Driver (Blocked / Slow Splunk / Disk I/O)

Demonstrate how a process freezes when stdout cannot be drained by creating a container that outputs logs faster than a congested driver can process.

# Launch container with high-volume logging
docker run --rm alpine sh -c 'while true; do dd if=/dev/urandom bs=1024 count=1 2>/dev/null | base64; done' > /dev/null
# If pipe consumer stops, the process enters 'S' (interruptible sleep) stuck on write()

Switch Docker's logging mode to `non-blocking`. In non-blocking mode, Docker places an in-memory ring buffer between the container and the logging driver. If the buffer fills, older log messages are dropped rather than blocking the application.

cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3",
    "mode": "non-blocking",
    "max-buffer-size": "8m"
  }
}
EOF

sudo systemctl reload docker

Launch containers and verify that during simulated collector downtime, application requests continue processing without interruption. Monitor Docker daemon log messages for buffer overflow warnings.

# Inspect container log configuration
docker inspect <CONTAINER_ID> --format '{{json .HostConfig.LogConfig}}' | jq .
# Output confirms "mode": "non-blocking", "max-buffer-size": "8m"