RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Antonio Murdaca
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2017-03-02 19:08:46 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
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 $?
    1

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
    container-selinux-2.7-1.el7.noarch
    docker-1.12.6-2.el7.x86_64
    docker-client-1.12.6-2.el7.x86_64
    ...

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.

https://rhn.redhat.com/errata/RHBA-2017-0406.html
Note You need to log in before you can comment on or make changes to this bug.