Hide Forgot
Description of problem: Container log output shouldn't show up in `journalctl -u docker` Version-Release number of selected component (if applicable): docker-1.11-5.git69e6294.fc25.x86_64 How reproducible: 100% Steps to Reproduce: 1. docker run --rm busybox echo HELLO JOURNAL 2. journalctl -u docker -ef Actual results: Apr 18 14:10:29 agoldste docker[4312]: HELLO JOURNAL Expected results: no container output in the journal for the docker unit
What is the journalctl command to get the container output? journalctl -u $containerid?
journalctl CONTAINER_ID=$short_id or journalctl CONTAINER_ID_FULL=$full_id
I am not sure if this is how this works. The problem here is the unit file is grabbing all stdout and stderr as it goes back to the client. This output would be the same if you used the json log or the journal log.
If you use the json logger, those entries don't show up in `journalctl -u docker`
The logged messages are not going to the journal when you use the json logger, so they wouldn't. When using the journald log driver, output is logged to the journal by the docker daemon on behalf of whatever's running inside of the container, so journald, which adds metadata to log entries describing where the message came from, assigns them metadata that attributes them to the docker daemon, which is why they get mixed in with messages that actually originate from the daemon. Adding an OBJECT_PID to messages (per systemd.journal-fields(5)) once it's available doesn't seem to be triggering the addition of metadata like OBJECT_SYSTEMD_UNIT, which could be a seperate problem. We can't override _MACHINE_ID from the docker daemon, either.
Accounting for whether or not forward-journald (per bug #1300076) is in use, journalctl -u docker _TRANSPORT=stdout + OBJECT_EXE=docker should filter the output down to just the messages that you want. The OBJECT_PID bug will be fixed fixed in systemd PR#3129. Without larger changes, journalctl -M won't be able to pull up a container's logs. I'm still looking at what will be required to make that work.
I don't think we're going to be able to change this. The simplest alternative to having the docker daemon send messages to the journal, which is what leads to those messages being counted along with other messages from the daemon, is to run a per-container journald and send messages to its listening socket. Basically, if the docker daemon is writing to the host's journal socket, the journald daemon is really, really good at figuring out that it's us. While logging a container's output to a journald instance running in a container would keep those messages from being mixed in with the daemon's, it's not something we can switch to doing as a general strategy because we can't guarantee that there's a journald to run in every container. In cases where there is one running, the journal files either live inside the container (i.e., they'd disappear when the container is destroyed, which would be a step back from having them survive, as they do now), or they'd be in a location that wouldn't be vacuumed automatically, which would likely require additional management to avoid running out of space. I'm going to mark this as can't-fix, then.