Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1420147 - read unix @->/var/run/docker.sock: read: connection reset by peer
Summary: read unix @->/var/run/docker.sock: read: connection reset by peer
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Antonio Murdaca
QA Contact: atomic-bugs@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2017-02-08 00:21 UTC by Ed Santiago
Modified: 2020-05-19 20:08 UTC (History)
6 users (show)

Fixed In Version: docker-1.12.6-9.el7_3
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-03-02 19:08:46 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0406 0 normal SHIPPED_LIVE docker bug fix and enhancement update 2017-03-03 00:06:50 UTC

Description Ed Santiago 2017-02-08 00:21:23 UTC
Today's docker build introduces a regression with -a (--attach) option:

    # echo true | docker run -a stdin -a stderr --tty=false centos
    read unix @->/var/run/docker.sock: read: connection reset by peer
    # echo $?

This is a regression. Expected: no output, exit status 0. Same error if we s/stderr/stdout/ but not if it's just -a stdin or just -a stdout. There may be other permutations I haven't tested.

    # rpm -qa|egrep 'docker|container-selinux'|sort

Not SELinux-related: problem persists with 'setenforce 0'.

Comment 1 Antonio Murdaca 2017-02-08 08:57:03 UTC
This backport https://github.com/projectatomic/docker/commit/e1d02aa55efa49c9d888b79f7c3ac44b5a24f72c from upstream https://github.com/docker/docker/pull/30446 caused this issue. I'm investigating a fix with upstream (since the backport is needed by openshift).

Comment 3 Ed Santiago 2017-02-14 15:09:05 UTC
Bug still present in yesterday's docker-1.12.6-3.el7 build

Comment 4 Antonio Murdaca 2017-02-14 15:21:27 UTC
This is still not fixed as per https://github.com/docker/docker/issues/30816

I don't have any use case in mind for such a test though and we're discussing whether to get rid of this behavior or not https://github.com/docker/docker/issues/30816#issuecomment-278311204

Comment 5 Antonio Murdaca 2017-02-20 09:56:54 UTC
Fixed in docker-1.12.6 - since this is for a patch release, I don't think getting rid of this functionality is nice. Upstream still has to decide and right now, the only sane thing we can do is to return at the old behavior (with https://github.com/jim-minter/docker/commit/1aa000451ced8c0c4034e667a33efb1cc9833fc9).

Comment 6 Chris Evich 2017-02-21 15:31:24 UTC
This is _not_ fixed in our builds of 1.12.6.  CI tests still failing as of docker/docker-latest-1.12.6-8.el7.x86_64.  Marking this as High and assuming higher-layers care about attaching to containers stdin/out/err not causing non-zero exits (and error messages) from the client.

Blocker?  I could certainly understand if it is, but that's not our call.

Comment 7 Antonio Murdaca 2017-02-21 15:44:37 UTC
Lokesh, could you rebuild from docker-1.12.6 branch?

Comment 8 Andy Goldstein 2017-02-21 16:51:34 UTC
I don't *think* this will cause a problem for Kube/OpenShift. When Kube creates a container, it always sets OpenStdin to true if the user requests stdin. You could opt to do -i (open stdin) and --attach=false, but that would still result in OpenStdin being set to true.

If we have run the OpenShift end to end tests using a version of docker that has this issue, OpenShift is probably ok. There's still a chance we're not, but I am having trouble reasoning through what scenario would cause a problem.

Comment 10 Ed Santiago 2017-02-21 23:11:03 UTC
Fix confirmed in docker-1.12.6-10.el7

Comment 12 errata-xmlrpc 2017-03-02 19:08:46 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.