moby: TTY Output Regression

Description

When using a recent master build including https://github.com/moby/moby/pull/33007 (to help kick the tires on the updated console-handling code), TTY output comes out garbled (presumably due to the lack of \r):

$ ./docker -H tcp://docker:2375 run -it --rm bash
bash-4.4# echo hi
                 hi
                   bash-4.4# 

Steps to reproduce the issue:

  1. create a master build (builds from https://master.dockerproject.org appear to be broken since https://github.com/moby/moby/pull/32694 was merged)
  2. launch dockerd
  3. run a container with an interactive shell and then invoke a command or two

Describe the results you received:

Cascading output!

Describe the results you expected:

Output aligned on the left margin, as in previous releases.

Output of docker version:

$ ./docker -H tcp://docker:2375 version
Client:
 Version:      library-import
 API version:  1.30
 Go version:   go1.8.1
 Git commit:   library-import
 Built:        library-import
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.0-dev
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.1
 Git commit:   4b846a1
 Built:        Tue May  9 05:00:50 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

$ ./docker -H tcp://docker:2375 info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 17.06.0-dev
Storage Driver: vfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: d24f39e203aa6be4944f06dd0fe38a618a36c764
runc version: 992a5be178a62e026f4069f443c6164912adbf09
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.4.63-gentoo
Operating System: Alpine Linux v3.5 (containerized)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.4GiB
Name: 33784326e3d3
ID: QKJH:XFQL:UCOR:56QQ:RZES:4YEQ:625G:3RQF:BAJJ:3TUW:Z4IE:GKE6
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: tianon
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Additional environment details (AWS, VirtualBox, physical, etc.):

I’m running the daemon via Docker-in-Docker, but my client is running directly on the host (connecting via TCP). I also tried running my host’s Docker client (17.04.0-ce) against the master daemon and got the same results.

Edit: I’ve reproduced on both 4.4.63-gentoo and 4.9.0-2-amd64 (from Debian).

cc @crosbymichael @cyphar

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 17 (15 by maintainers)

Commits related to this issue

Most upvoted comments

Grrr. This is related to the changes I made to runc which un-set the ONLCR termios flag – which means that runc now acts like a normal program’s output (the trailing \r\n was breaking a bunch of our tests and will cause countless issues in shell scripts).

However this appears to break Docker in certain cases (which I haven’t been able to reproduce), and it looks to me like there’s something weird going on when the bytes are being shifted from runc into containerd and then into Docker. To be clear the current semantics from runc make sense if you were a normal program (creating a pty inside runc results in the extra \r which shouldn’t be seen IMO).