Find Docker daemon logs

On a systemd-managed Linux Docker Engine host, start with journalctl -u docker.service. These records describe the Docker daemon's own startup, networking, storage, and runtime activity. They are separate from a container application's stdout and stderr.

Linux hosts

sudo journalctl -u docker.service -n 100 --no-pager
sudo journalctl -u docker.service -f
sudo journalctl -u docker.service --since '1 hour ago'

For a rootless installation managed as a user service, use the relevant user's journal:

journalctl --user -u docker.service -n 100 --no-pager

On non-systemd installations, inspect the actual service manager or launch command. Possible destinations include /var/log/docker.log, /var/log/messages, /var/log/syslog, or the launching terminal; none is universal.

Journal priority filtering such as -p err helps only when the priority stored in the journal reflects the daemon event level. Do not assume a textual level=error inside a captured stdout line is always mapped to the journal's error priority.

Docker Desktop

Docker Desktop runs the Linux engine inside a managed VM. The macOS host's process logs alone are not a complete view of dockerd.

Common diagnostic roots include:

• macOS: ~/Library/Containers/com.docker.docker/Data/log/, including VM logs where supplied by that version.
• Windows: %LOCALAPPDATA%\Docker\log\, with backend-specific host and VM records.

Use Docker Desktop's Troubleshoot/diagnostic workflow and the installed version's documented paths. VM backends and file names can change. For native Windows Docker Engine, consult its Windows event-log configuration rather than assuming Desktop's directory applies.

Adjust daemon verbosity deliberately

A daemon configuration can include:

{
  "log-level": "info",
  "debug": false
}

Merge settings with the existing configuration and check for conflicting startup flags. Enabling debug can help a bounded investigation but increases detail and volume. Apply changes using the installation's documented reload or restart procedure, considering running workloads, then restore normal verbosity.

Distinguish container logs

docker logs --tail 100 my-container
docker inspect --format '{{json .HostConfig.LogConfig}}' my-container

These inspect application output and the container's logging driver. Only some drivers store readable local files, and their paths can vary. For json-file, configure rotation such as max-size and max-file for newly created containers; do not edit the internal file to change its destination or retention.

If daemon output is deliberately written to a host file, DataKit file-log collection can collect that destination. For a journal source, use a collection method that actually reads the journal. Seeing application logs in a platform does not prove daemon diagnostics are collected.

FAQ

How do I narrow a noisy investigation?

Use a time window, service unit, and the exact error or container/image identifier. Preserve surrounding startup or retry context before filtering too aggressively.

Why is journalctl empty?

Confirm the host, rootful versus rootless service, unit name, permissions, and whether Docker Desktop is running the engine elsewhere. The machine running the Docker CLI need not be the daemon host.

How do I know collection works?

Choose an operation expected to produce a diagnostic at the configured level, inspect it locally, and then verify the same record at the destination. An ordinary successful image pull is not guaranteed to emit the record you expect at every log level.

Reference: Docker daemon log locations.