Docker Daemon Log Driver and Log Opts in relation to Conjur Setup

Good afternoon,

Some time ago a resource assisted us with setting up Conjur and instructed us during setup to populate a daemon.json for Docker that contained only the following content:

“log-driver”: “journald”

Now that our instance of Conjur is seeing regular use, log files are beginning to pose a problem with regards to memory/space usage. We wanted to address the issue by using “log-opts” to limit file number and size.

However, when we attempt to do this (either within the daemon.json or on the container we’re running), we get the following error:

docker: Error response from daemon: unknown log opt ‘max-size’/‘max-file’/etc for journald log driver.

This implies journald doesn’t support log-opt; thus we may need to switch to a different kind of log driver, specifically json-file.

Is there any reason why Journald was recommended to us? If we were to use something else, would it be disruptive to Conjur’s functionality? Would json-file still work?

Hey N.R.,

We give journals as our recommendation based on the limitations / abilities in Docker Community Edition (CE), which can be found at . From that site: "When using Docker Community Engine, the docker logs command is only available on the following drivers: local, json-file, journald"

We chose to recommend journald because it is the only one of the three that support both docker logs for local troubleshooting on the host and can be configured to forward log messages to rsyslogd to be sent to remote syslog endpoints (such as a SIEM). This can also be done with json-file but the output isn’t as clean and the overhead of running a file monitor on the json files is usually more resource intensive than configuring journald/rsyslogd.

There are ways to configure journald on the host system to manage the journal size and rotation settings, and it can be done without having to redeploy the conjur container. I found a related page at .

Typically the default settings are okay, but in cases where these settings need to be changed we recommend that customers contact their internal Linux support teams and/or OS vendor (typically Redhat) to figure out the optimal settings for their environment.