Blocked keyboard input after entering a container

[HarryMichal]

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

/kind bug

Description

After entering a container with podman exec -it containername /bin/sh the keyboard input can be blocked by typing anything during the time between executing mentioned command and getting shell. By blocked I mean any kind of input in the terminal session from typing classic characters or Ctrl+C or anything else. The only way out is to kill the session and open a new one.

Steps to reproduce the issue:

1. podman pull alpine
2. podman create alpine sleep 100000
3. podman start --latest
4. podman exec -itl --latest /bin/sh (after executing this, type anything on the keyboard, before entering the container)

Describe the results you received:
Unresponsive terminal session with shell prompt

Describe the results you expected:
Responsive terminal session with shell prompt

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

Output of podman version:

Version:            1.6.1
RemoteAPI Version:  1
Go Version:         go1.12.9
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.12.9
  podman version: 1.6.1
host:
  BuildahVersion: 1.11.2
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.1-1.fc30.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.1, commit: 4346fbe0b2634b05857973bdf663598081240374'
  Distribution:
    distribution: fedora
    version: "30"
  MemFree: 2768666624
  MemTotal: 16659148800
  OCIRuntime:
    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: 7978872832
  SwapTotal: 8413769728
  arch: amd64
  cpus: 8
  eventlogger: journald
  hostname: harry-work
  kernel: 5.3.6-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: 4h 44m 43.56s (Approximately 0.17 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/omichal/.config/containers/storage.conf
  ContainerStore:
    number: 6
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.6.4-2.fc30.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.6.4
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /var/home/omichal/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 8
  RunRoot: /run/user/1000
  VolumePath: /var/home/omichal/.local/share/containers/storage/volumes

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

podman-1.6.1-2.fc30.x86_64

Additional environment details (AWS, VirtualBox, physical, etc.):
Running Fedora Silverblue 30

[mheon]

Can you also reproduce this problem with podman run?

@haircommander PTAL - could this be the way we handle sync for podman exec?

[haircommander]

I could not reproduce with run, but could with exec

[haircommander]

the cause is currently a mystery to me, I'm gonna poke around for a bit

[fbruetting]

This now is the case again with Toolbox 0.0.18-1 and podman 1.8.0-2 on FSB31. Can anyone reproduce?

[HarryMichal]

@fbruetting Yeah, I can reproduce it with both Toolbox container and the steps in the original issue.

toolbox-0.0.18-1.fc31.noarch, podman-1.8.0-2.fc31.x86_64, crun-0.12.1-1.fc31.x86_64

[fbruetting]

Can someone reopen then?

[TomSweeneyRedHat]

Reopening and I wonder if #5203 at least helps to address this?

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@HarryMichal Do you still have this issue?

[HarryMichal]

Yes, I still do. But on version 1.8.0. I currently don't have 1.8.1 installed on my system.

[felipeborges]

I have podman 1.8.1-dev and I still have the issue.

[debarshiray]

I have been hitting this too on Fedora 31. I have:

podman-1.8.2-2.fc31.x86_64
conmon-2.0.14-1.fc31.x86_64
crun-0.13-1.fc31.x86_64

[Shai-Aviv]

I'm hitting this on Fedora 32 with:

• podman-1.9.1-1.fc32.x86_64
• conmon-2.0.15-1.fc32.x86_64
• crun-0.13-2.fc32.x86_64

[rhatdan]

Do you have a reproducer we could play with?

[Shai-Aviv]

@rhatdan Yes, I have a reproducer. Please run this:

podman run -dit --name too_fast docker.io/library/alpine

then copy and paste these lines (in one go, with the newline) into a shell:

podman exec -it too_fast sh
echo "I'm typing waaay too fast."

Every time I run this, I get an interactive shell that:

• Hangs
• Does not respond to CTRL-c or CTRL-d
• Only closes when I hit CTRL-p CTRL-q (after some noticeable delay) with this error:

  ERRO[0014] Container 52bf51ab892931935d82b51a64aa1e8bf64e7813562a94f2725101be75654d01 exec session 20e4705534cc3b0ffdd3a108cec5a0cb208d6f41448bdf0207b475ca861c0e3c error: detached from container 
  Error: timed out waiting for file /home/shayaviv/.local/share/containers/storage/overlay-containers/52bf51ab892931935d82b51a64aa1e8bf64e7813562a94f2725101be75654d01/userdata/20e4705534cc3b0ffdd3a108cec5a0cb208d6f41448bdf0207b475ca861c0e3c/exit/52bf51ab892931935d82b51a64aa1e8bf64e7813562a94f2725101be75654d01: internal libpod error
  

[rhatdan]

Nice, @mheon @haircommander Does this help you guys out?