Docker container logs filling your Mac disk

Part of: Docker disk space on Mac: Docker.raw, images and build cache explained (Docker)

Docker keeps a log file for every container, and by default it never rotates it. A container that prints a lot can grow a log without limit. On a Mac that growth happens inside Docker’s disk image, so you will not find the log in a normal folder.

Where the log lives

On a Mac, the Docker engine runs inside a Linux virtual machine. The log files are in that VM, not in your home folder. You can ask Docker for the path:

docker inspect --format '{{.LogPath}}' <container-name>

On the Colima setup used to check this article (if Colima’s own disk fills up, see Colima disk full), it printed a path under /var/lib/docker/containers/, inside the VM. That is why Finder never shows these files. Docker Desktop also stores containers and images in a single disk image, according to its Mac FAQ, so the logs add to the size of that image.

To check the logging driver, run:

docker info --format '{{.LoggingDriver}}'

On that setup this printed json-file, which is Docker’s default.

Why it grows

Docker’s documentation for the json-file driver lists the defaults for its rotation options: max-size is -1, which means unlimited, and max-file is 1. So unless you set a limit, nothing rotates. It also says log files persist until their container is removed, and rotation does not delete them after the fact.

A stopped container keeps its log. A container that has been running for months with verbose output can hold a surprisingly large one.

What to do about it

Two steps: remove what is already there, and set limits so it does not happen again.

Remove an old log by removing its container. The docs say logs persist until the container is removed. If a container is stopped and you do not need it, removing it removes its log. If it is one you need, you can recreate it with new settings. Check which container is using the space before you remove it.

Set limits. The json-file driver has two options, both documented:

• max-size: how big a log file may get before Docker rotates it.
• max-file: how many rotated files to keep. The docs note it is only effective when max-size is also set.

For all containers, Docker’s page shows this daemon.json example. Note that all values must be strings:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

You can also pass the same two options for a single container when you start it. We did not apply either setting while writing this, so we cannot show you the result. Check Docker’s documentation for how your version applies engine settings to containers that already exist.

Fix the source too

A limit stops the growth, but a container that prints thousands of lines a minute is usually telling you something. A debug level left switched on, a retry loop or an error repeated forever are common reasons. If you own the application, lowering its log level helps more than any rotation setting, and it makes the log readable again.

Safe, risky, never

Checking whether logs are your problem

Run docker system df first. It is read-only and shows images, containers, volumes and build cache. Container logs are not a separate row, so a large unexplained gap between those numbers and the disk image size can be a hint, but only a hint.

If the numbers do not add up, the Docker.raw guide explains why a disk image can look larger than the data in it, and the overview lists the other places Docker space goes. If the build cache is the bigger number, see how to clean the Docker build cache.

Quick checklist

1. Run docker system df and note the sizes.
2. Check the logging driver with the docker info command shown above.
3. Look up the log path of the container you suspect.
4. Decide whether the container is still needed.
5. Set max-size and max-file so the next one stays small.

How DiskJoy fits in

DiskJoy is our product. It is pre-alpha and it only scans your Mac. Its scan reports allocated size on disk, and its reclaimable figure, where shown, is a lower-bound estimate that excludes shared extents, not an exact number. Container logs live inside Docker’s virtual disk, which a scan sees as one file. Cleanup is not built yet, so it does not remove any logs. The download page shows the current status of the scan.