APIv2: Query after killing rootless hangs forever

[marusak]

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

/kind bug

Description
In Cockpit we test how the UI behaves when podman dies,when only one is running (root/rootless)... To do that, we stop/kill sockets, services and processes. There seems to be a problem with rootless where it is not possible to connect once the process was terminated.

Steps to reproduce the issue:

1. ./script.sh script.sh
   Note 1: It may succeed the first time (especially if freshly booted system), then you might need to re-run it
   Note 2: Drop --user from all calls, change the unix path in the last call and run it as root, it all works as expected

Describe the results you received:
The script hangs forever. If you ^C it and then call curl --unix-socket /run/user/1000/podman/podman.sock http://d/v1.24/libpod/info bunch of times, eventually it succeeds. (other calls don't hang, they just Couldn't connect to server.

Describe the results you expected:

1. The call would not hang.
2. The call would always succeed on first, second or any other try (as does root one)

Output of podman version:

Version:      2.0.0-rc6
API Version:  1
Go Version:   go1.14.3
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.15.0-dev
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.17-1.fc32.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.17, commit: bb8e273f5925c1a51737644637ef65d094a67ab1'
  cpus: 4
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: file
  hostname: zahlmaschine
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 1935008
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 1935008
      size: 65536
  kernel: 5.6.11-300.fc32.x86_64
  linkmode: dynamic
  memFree: 391274496
  memTotal: 16418353152
  ociRuntime:
    name: crun
    package: crun-0.13-2.fc32.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.13
      commit: e79e4de4ac16da0ce48777afb72c6241de870525
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.0.0-1.fc32.x86_64
    version: |-
      slirp4netns version 1.0.0
      commit: a3be729152a33e692cd28b52f664defbf2e7810a
      libslirp: 4.2.0
  swapFree: 0
  swapTotal: 0
  uptime: 72h 9m 48.16s (Approximately 3.00 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/mmarusak/.config/containers/storage.conf
  containerStore:
    number: 24
    paused: 0
    running: 0
    stopped: 24
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.0.0-1.fc32.x86_64
      Version: |-
        fusermount3 version: 3.9.1
        fuse-overlayfs: version 1.0.0
        FUSE library version 3.9.1
        using FUSE kernel interface version 7.31
  graphRoot: /home/mmarusak/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 3
  runRoot: /run/user/1000
  volumePath: /home/mmarusak/.local/share/containers/storage/volumes
version:
  APIVersion: 1
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.14.3
  OsArch: linux/amd64
  Version: 2.0.0-rc6

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

podman-2.0.0-0.2.rc6.fc32.x86_64

[marusak]

@jwhonce can you reproduce this and confirm that it is an actual problem?

[github-actions]

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

[rhatdan]

@marusak @jwhonce Is this still an issue?

[marusak]

The script still reproduces it for me.

[vrothberg]

@jwhonce PTAL

[giuseppe]

could you give a try to #7192 ?

I've used your script I was able to see the issue locally. With that patch applied Podman seems to work fine now