podman pull does not suspend properly (ctrl-z)

[phlogistonjohn]

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

/kind bug

Description

Attempting to suspend podman pull, using ctrl-z in a shell, does not suspend all processes and leaves the command in a "stuck" state.

Steps to reproduce the issue:

1. podman pull -q foo/bar:baz

2. CTRL-Z

3. Shell is non-respnsive. CTRL-C, etc do nothing

Describe the results you received:

podman command line does not suspend

Describe the results you expected:

podman process is suspended like a typical shell command, allowing subsequent job-control commands such as "bg"

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

This can be worked around by finding the pid of the podman child process which is suspended and running kill -CONT <pid> on it. The child process will then either continue or die (depending on what else you did in the original shell) and the parent process will exit.
This seems to be some sort of signal handling issue.
This probably effects other podman subcommands but I only checked "pull" as it is frequently where I start a pull, realize its really pulling from the internet and decide I'd rather background it with "bg", but this workflow fails.

Output of podman version:

Version:            1.1.2
RemoteAPI Version:  1
Go Version:         go1.11.5
Git Commit:         a95a49d3038462d033f84ac314ec8a3064a99cff
Built:              Tue Mar  5 13:10:31 2019
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: a95a49d3038462d033f84ac314ec8a3064a99cff
  go version: go1.11.5
  podman version: 1.1.2
host:
  BuildahVersion: 1.7.1
  Conmon:
    package: podman-1.1.2-1.git0ad9b6b.fc29.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: a95a49d3038462d033f84ac314ec8a3064a99cff'
  Distribution:
    distribution: fedora
    version: "29"
  MemFree: 6417608704
  MemTotal: 32940503040
  OCIRuntime:
    package: runc-1.0.0-68.dev.git6635b4f.fc29.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc6+dev
      commit: ef9132178ccc3d2775d4fb51f1e431f30cac1398-dirty
      spec: 1.0.1-dev
  SwapFree: 16542330880
  SwapTotal: 16542330880
  arch: amd64
  cpus: 8
  hostname: popcorn
  kernel: 5.0.3-200.fc29.x86_64
  os: linux
  rootless: true
  uptime: 29h 24m 59.5s (Approximately 1.21 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/jmulliga/.config/containers/storage.conf
  ContainerStore:
    number: 64
  GraphDriverName: vfs
  GraphOptions:
  - vfs.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/jmulliga/.local/share/containers/storage
  GraphStatus: {}
  ImageStore:
    number: 176
  RunRoot: /run/user/1000
  VolumePath: /home/jmulliga/.local/share/containers/storage/volumes

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

Developer laptop, fedora 29, bash shell

[mheon]

Happens exclusively as rootless. Probably something to do with the rootless user namespace. @giuseppe any ideas here?

[giuseppe]

This probably happens as we have two processes and we don't propagate signals.

[mheon]

We can't really catch and forward SIGSTOP anyways - uncatchable by design. I don't really know what we can do here, then.

[giuseppe]

Once we land the rootless refactoring, I'd like to redesign the re-exec in a way of not having two processes

[giuseppe]

can you try if #2915 solves the problem for you?

[phlogistonjohn]

Yes. That appears to do the trick. Thanks!