podman exec with heredoc results in read: connection reset by peer

[pkubatrh]

/kind bug

Description

Recently I noticed our CI test failing when exec-ing into a running postgresql container and feeding it input using heredoc.

Steps to reproduce the issue:

1. podman run -e POSTGRESQL_ADMIN_PASSWORD=test -d --name postgresql registry.access.redhat.com/rhscl/postgresql-10-rhel7

2. podman exec -i postgresql cat < testing input
   EOF

Describe the results you received:
Error: read unixpacket @->/var/run/libpod/socket/c32a489545c3322cc24752af4af08df221aa2d2fa3e25a5affbd7dfe38bef8b6/attach: read: connection reset by peer

Describe the results you expected:
testing input

Additional information you deem important (e.g. issue happens only occasionally):

Container run as root.
When I hit it in the postgresql CI tests (feeding data into the db) even the error message did not get printed, the command succeeded, but data was not in the container.
Note that this does work with docker:

# docker-binary run -e POSTGRESQL_ADMIN_PASSWORD=test -d --name postgresql rhscl/postgresql-10-rhel7   
904d31577c8bde39239cefcef357225bf561847b3a72944738d87bd46c8b701e
# docker-binary exec -i postgresql cat <<EOF
testing input
EOF
testing input

Output of podman version:

Version:            1.6.2
RemoteAPI Version:  1
Go Version:         go1.12.10
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.12.10
  podman version: 1.6.2
host:
  BuildahVersion: 1.11.3
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.2-1.fc30.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.2, commit: a89d21975ee86e84e0b0e1c0f887687582f4b0e3'
  Distribution:
    distribution: fedora
    version: "30"
  IDMappings:
    gidmap:
    - container_id: 0
      host_id: 21722
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 21722
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  MemFree: 22932959232
  MemTotal: 33516740608
  OCIRuntime:
    name: runc
    package: runc-1.0.0-95.rc9.gitc1485a1.fc30.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc9+dev
      commit: 0840802d505e28d3adcbc7a275cbeadbdf64ddec
      spec: 1.0.1-dev
  SwapFree: 16852709376
  SwapTotal: 16852709376
  arch: amd64
  cpus: 8
  eventlogger: journald
  hostname: localhost.localdomain
  kernel: 5.3.7-200.fc30.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.0-4.git19d199a.fc30.x86_64
    Version: |-
      slirp4netns version 0.4.0-beta.2
      commit: 19d199a6ca424fcf9516320a327cedad85cf4dfb
  uptime: 6h 40m 42.85s (Approximately 0.25 days)
registries:
  blocked: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/pkubat/.config/containers/storage.conf
  ContainerStore:
    number: 12
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.6.5-2.fc30.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.6.5
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /home/pkubat/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 23
  RunRoot: /run/user/21722
  VolumePath: /home/pkubat/.local/share/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):

podman-1.6.2-2.fc30.x86_64

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

[pkubatrh]

Ah sorry, I see its probably a dupe of #4326. Should have searched before posting :/

[vrothberg]

Thanks a lot for reaching out, @pkubatrh! I also think that it's a dupe of #4326 which will be fixed with Podman v1.6.3 which will reach you soon on Fedora.

[yanchenko-igor]

@vrothberg How do you know in which version it's going to be fixed? it's not fixed in master branch yet.

[vrothberg]

My bad. It's not yet fixed entirely. Thanks for pointing that out!