Missing Logspout logs for containers running with TTY enabled

[nma]

Just setup a logspout to test it out. Love the ease of use of the tool!

Though I am running into issues with a certain docker-compose v1 template.

serviceA:
  image: org/serviceA
  log_driver: 'json-file'
  log_opt:
    max-file: '1'
    max-size: '2M'

I noticed in my graylog setup that logspout is not sending any logging details for this service.
When I remove my custom log_driver and log_opt the problem is still not fixed.

The only way for me to get logspout extracting details from the container of serviceA is when I run it outside of docker-compose.

docker run org/serviceA

So I am curious as to why some containers in a docker-compose does not get picked up by logspout? Is this a known issue?

[nma]

I read the documentation a few times and found the culprit. The -t option was set in the docker-compose file. In docker compose tty: true equates to the -t option being set.

This was why it was not working.

Though a next curiosity, what aspects of the -t option cause logspout to not be able to route logs? Any pointers to code sections or docs explaining it?

[josegonzalez]

We ignore logs from containers with tty: https://github.com/gliderlabs/logspout/blame/a415f5d090c9a5ffd004cbbee61da9466e3077be/router/pump.go#L148

@progrium Looking at the blame/history, nothing strikes me as to why we ignore those logs. Any particular reasons?

[johnrengelman]

Would be great to be able to disable this feature and rely only on LOGSPOUT_IGNORE. Simplifies things in a PaaS type system where developers might not be aware of the impact of certain settings.

[martinbaillie]

I stumbled upon this after forking and patching logspout to use RawTerminal in the docker client LogsOptions. This gets around the tty thing. Would you be interested in a PR to make it configurable?

[untoldone]

@martinbaillie ever end up making a pull request? Alternatively do you have a docker-hub version of your branch?

[martinbaillie]

@untoldone No, I didn't and have nothing on Dockerhub. However I am using it at my current company in production. A vanilla Dockerfile might look something like this:

FROM alpine
RUN apk add --update git && \
        # Logspout + Rancher tty patch
        git clone --depth 1 https://github.com/martinbaillie/logspout.git /src && \
        git clone --depth 1 https://github.com/looplab/logspout-logstash.git \
        /src/adapters/logstash
COPY ./modules.go /src/modules.go
RUN cd /src && ./build.sh $(cat VERSION)-martinbaillie && rm -rf /src
ENTRYPOINT /bin/logspout

[untoldone]

@martinbaillie Thanks! Super helpful

[michaelshobbs]

My understanding is that most folks don't want to log interactive containers because the assumption is that those would most likely be for debugging or something of that nature. Relying on LOGSPOUT_IGNORE wouldn't prevent these one-off containers from getting logged.

I'm sort of 👎 on removing the TTY constraint. However, making that user configurable seems reasonable. Anybody want to work on that?

[johnrengelman]

I think @davidnortonjr has a patch for this in a fork somewhere.

[untoldone]

@michaelshobbs There are more reasons to use interactive than just for one-off containers. It is also very useful in making production systems more debugable. I use it in production to be able to do things like docker logs -f without a 60 second timeout (docker/compose#3633) and to enable interactive debugging when something does go wrong in production.

[michaelshobbs]

@untoldone Understood. Support for ALLOW_TTY was merged in 2c78014 and will be in the next release. You can also run gliderlabs/logspout:master if you want the functionality now.

[untoldone]

@michaelshobbs Thanks!

[raravena80]

This doesn't seem to be working form me on master. Is this the right command?

docker run --rm -e ALLOW_TTY=true -e DEBUG=true -d --name="logspout" --volume=/var/run/docker.sock:/var/run/docker.sock --publish=0.0.0.0:8000:80 gliderlabs/logspout:master