Linux – Docker daemon.json logging configuration is invalid

I have a mongodb docker container (stock downloaded from docker repo). Its log size is unlimited (/var/lib.docker/containers/’container_id’/’container_id’-json.log).

This recently caused the server to fill up, so I found that I could instruct the docker daemon to limit the maximum size of the container log file and the number of log files it will retain after the split. (Please forgive my naivety. It’s a tool environment, so things can be set up to meet immediate needs, and often a lack of planning is painful.)

Stopping containers is not advisable (although it won’t bring the end of the world), so it might be a suitable plan to do G.

Through experimentation, I found that running different instances of the same docker image and containing —log-opt max-size=1m --log-opt max-file=3 did what I wanted well in the docker run command.

I

learned that I can include it in the docker daemon.json file so that it works globally across all containers. I tried adding the following to the file “/etc/docker/daemon.json”

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

Then I sent a -SIGHUP to the daemon. I did observe that the daemon’s logs spit out some information about the reload configuration, and it mentions the exact file path I edited. (Note: This file didn’t exist before, I created it and added content.) This has no effect on the log output of a running Mongo container.

After reloading the daemon, I also tried instantiating a different instance of the Mongo container again, but it also didn’t follow the logging instructions that the daemon should have. I see that its logs exceed the 10m mark and keep going.

My question is:

1. Should there be a way to update logging via daemon to affect running containers?
2. If not, is there a way to tell the container to reload this information at runtime? (I see docker update, but this doesn’t seem to be one of the configuration options that can be updated.)
3. Is there a problem with my configuration? I tested a pointless instruction to see if the error would silently fail when they didn’t. An instruction that is not in mode throws an error in the daemon’s log. This indicates that what I added (as shown above) is at least what is expected, although it may be incomplete or otherwise. These commands appear to work in the run command, but not in the configuration. Also, I initially tried to include “3” as a number, but this also threw an error that disappeared when I stringified it.

I

4. did see different instances of the Mongo container in the file ‘/var/lib.docker/containers/’container_id’/hostconfig.json”, which I included instructions to run commands that set up visibility. Is it valid/safe to manually edit this file for production instances of Mongo containers to match the configuration of different proof-of-concept containers?

See some system details below:

• Docker version 1.10.3, build 20f81dd
• Ubuntu 14.04.1 LTS

My main goal is to understand why the global configuration doesn’t seem to work, and if there is a way to make this change to a running container without disrupting the container.

Thank you in advance for your help!

This setting becomes the new default for newly created containers, not existing containers, even if they are restarted. The newly created container will have a new container ID. I emphasize this because a lot of people (myself included) are trying to change the log settings on an existing container without first deleting that container (they may have already created a pet), and there’s no supported way to do this in docker.

Instead of stopping the docker engine completely, you can simply run the reload command to apply this change. However, some methods of running Docker, such as Docker in desktop environments and Docker-based installations, may require an engine restart without a simple reload option.

This setting limits the JSON file to 3 separate 10-megabytes files, or 20-30 megabytes of logs, depending on exactly where the third log happens to be in the file. Once you fill up the third file, the oldest log is deleted, bringing you back to 20 megabytes, performing rotation in the other logs, and starting a new log file. However, JSON has a lot of overhead, about 50% in my tests, which means you’ll get about 10-15 megabytes of application output.

Note that this setting is only the default setting and can be overridden by any container. So, if you find no effect, double-check how the container was started to verify that no log options were passed there.