Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker/podman difference when piping to exec statement #4785

Closed
yourcase opened this issue Jan 3, 2020 · 3 comments · Fixed by #4818
Closed

Docker/podman difference when piping to exec statement #4785

yourcase opened this issue Jan 3, 2020 · 3 comments · Fixed by #4818
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@yourcase
Copy link

yourcase commented Jan 3, 2020

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Piping to stdin of a podman exec statement behaves differently from piping to docker exec

Steps to reproduce the issue:

  1. On Fedora 31:
$ uname -a
Linux desk004.dabusiness.com 5.3.16-300.fc31.x86_64 #1 SMP Fri Dec 13 17:59:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -q docker podman
docker-1.13.1-68.git47e2230.fc30.x86_64
podman-1.6.2-2.fc31.x86_64

  1. Open a terminal and type
$ sudo docker run -ti --name f31c fedora:31

Open a second terminal and type

$ echo abc | sudo docker exec -i f31c cat
abc
$

note the output abc

  1. Open a terminal and type
$ sudo podman run -ti --name f31c fedora:31

Open a second terminal and type

$ echo abc | sudo podman exec -i f31c cat
$

note the absence of any output

Describe the results you received:
Stdin doesn't seem to get piped to podman exec's argument statement, whereas it does seem to get piped to docker exec's argument statement. This doesn't follow from the example above, but more complex cases, like piping a database dump to a database, and the database not having been altered in the podman case, would suggest this.

Describe the results you expected:
I would have expected podman and docker to behave in the same way

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

Output of podman version:

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

Output of podman info --debug:

Version:            1.6.2
RemoteAPI Version:  1
Go Version:         go1.13.1
OS/Arch:            linux/amd64
[dauser@desk004 midasdb]$ podman info --debug
debug:
  compiler: gc
  git commit: ""
  go version: go1.13.1
  podman version: 1.6.2
host:
  BuildahVersion: 1.11.3
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.2-1.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.2, commit: 186a550ba0866ce799d74006dab97969a2107979'
  Distribution:
    distribution: fedora
    version: "31"
  IDMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  MemFree: 357253120
  MemTotal: 16656502784
  OCIRuntime:
    name: crun
    package: crun-0.10.6-1.fc31.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.10.6
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  SwapFree: 8304193536
  SwapTotal: 8413769728
  arch: amd64
  cpus: 4
  eventlogger: journald
  hostname: desk004.dabusiness.com
  kernel: 5.3.16-300.fc31.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.0-20.1.dev.gitbbd6f25.fc31.x86_64
    Version: |-
      slirp4netns version 0.4.0-beta.3+dev
      commit: bbd6f25c70d5db2a1cd3bfb0416a8db99a75ed7e
  uptime: 9h 58m 37.16s (Approximately 0.38 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
store:
  ConfigFile: /home/dauser/.config/containers/storage.conf
  ContainerStore:
    number: 0
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.7.2-2.fc31.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.7.2
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /home/dauser/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 4
  RunRoot: /run/user/1000
  VolumePath: /home/dauser/.local/share/containers/storage/volumes

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

docker-1.13.1-68.git47e2230.fc30.x86_64
podman-1.6.2-2.fc31.x86_64

Additional environment details (AWS, VirtualBox, physical, etc.):
Fedora 31 running on hardware.

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Jan 3, 2020
@giuseppe
Copy link
Member

giuseppe commented Jan 5, 2020

it seems crun is correctly passing down stdin.

It might be conmon, @haircommander is it something we support in conmon now?

@mheon
Copy link
Member

mheon commented Jan 5, 2020 via email

@haircommander
Copy link
Collaborator

this is the same problem as #4326 and #3302
basically, pipes in golang are a bit funky, and conmon sees the piped output as empty, so assumes stdin is done and closes. I haven't figured out a work around yet.

edsantiago added a commit to edsantiago/libpod that referenced this issue Jan 9, 2020
- run: --name (includes 'podman container exists' tests)
- run: --pull (always, never, missing)
- build: new test for ADD URL (containers#4420)
- exec: new test for issue containers#4785 (pipe getting lost)
- diff: new test
- selinux (mostly copied from docker-autotest)

Plus a bug fix: the wait_for_output() helper would continue
checking, eventually timing out, even if the container had
already exited (probably because of an error). Fix: as
part of the loop, run 'podman inspect' and bail out if
container is not running. Include exit code and logs.

Signed-off-by: Ed Santiago <santiago@redhat.com>
edsantiago added a commit to edsantiago/libpod that referenced this issue Jan 9, 2020
- run: --name (includes 'podman container exists' tests)
- run: --pull (always, never, missing)
- build: new test for ADD URL (containers#4420)
- exec: new test for issue containers#4785 (pipe getting lost)
- diff: new test
- selinux (mostly copied from docker-autotest)

Plus a bug fix: the wait_for_output() helper would continue
checking, eventually timing out, even if the container had
already exited (probably because of an error). Fix: as
part of the loop, run 'podman inspect' and bail out if
container is not running. Include exit code and logs.

Signed-off-by: Ed Santiago <santiago@redhat.com>
edsantiago added a commit to edsantiago/libpod that referenced this issue Jan 13, 2020
- run: --name (includes 'podman container exists' tests)
- run: --pull (always, never, missing)
- build: new test for ADD URL (containers#4420)
- exec: new test for issue containers#4785 (pipe getting lost)
- diff: new test
- selinux (mostly copied from docker-autotest)

Plus a bug fix: the wait_for_output() helper would continue
checking, eventually timing out, even if the container had
already exited (probably because of an error). Fix: as
part of the loop, run 'podman inspect' and bail out if
container is not running. Include exit code and logs.

Signed-off-by: Ed Santiago <santiago@redhat.com>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants