Bug 1113092
| Summary: | `docker run` fails when attaching stderr in tty mode | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Lukáš Doktor <ldoktor> | ||||
| Component: | docker | Assignee: | Matthew Heon <mheon> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.0 | CC: | bsarathy, dwalsh, jrieden, mheon, mjenner | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-09-18 20:45:53 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1109938 | ||||||
| Attachments: |
|
||||||
Is there a reason why -a is allowed to be run with -t? Starting with -t implies that the stdin/out/err of the docker run process will all be attached to the new TTY; I don't see how attaching one of these signals again makes sense in that context. Running -a stdout -t, for example, breaks attaching stdin. Given this, I propose ignoring -a flags if -t is active. I'll raise this with upstream and see if they think this is a reasonable solution. I was thinking the same thing. We can make the -a and -t conflict with each other if upstream agrees. Issue created upstream about this: https://github.com/dotcloud/docker/issues/6736 It would be nice to make -a and -t conflict. Upstream feels that there are use cases where -a and -t may be used together. I've identified the root cause of the bug, though, and will be submitting a patch for it soon (https://github.com/dotcloud/docker/issues/6983) Patch has been accepted by upstream. We'll be carrying it in our builds of Docker for RHEL7. Fixed in docker-1.1.1-1 Hi Matthew, I can confirm it's not crashing. Unluckily I'm not convinced it works fine yet. I tested it with `ls non_existing_file` which should print into stderr "ls: cannot access non_existing_file: No such file or directory". When I use tty mode, it's printing it into stdout, when I use non-tty mode it prints it correctly into stderr: TTY: [root@localhost ~]# docker run -t -a stderr fedora ls non_existing_file [root@localhost ~]# docker run -t -a stdout fedora ls non_existing_file ls: cannot access non_existing_file: No such file or directory NON-TTY: [root@localhost ~]# docker run -a stderr fedora ls non_existing_file ls: cannot access non_existing_file: No such file or directory [root@localhost ~]# docker run -a stdout fedora ls non_existing_file Confirmed, I can reproduce this locally. This looks to be a server-side issue - in TTY mode, the server seems to multiplex stdout into stderr, which the client is unaware of. I'll look into fixing this. OK, thank you. I'll set this to `verified` as it's not crashing now and create new BZ for the stdout/stderr multiplex issue to not lost the track... Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1266.html |
Created attachment 912078 [details] output of "docker -D run -a stderr -t fedora bash -c exit" command Description of problem: When I try to attach `-a stderr`, the process raises exception with nil pointer dereference. Version-Release number of selected component (if applicable): docker-0.11.1-10.el7.x86_64 docker-io-1.0.0-1.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. docker -D run -a stderr -t fedora bash Actual results: failure - tb attached Expected results: container should start Additional info: In non-tty mode it works perfectly.