while exiting `podman exec` pinging error occurs

[CooolRyan]

Issue Description

Describe your issue

when using podman exec (whatever command you use thereafter) pinging error occurs.

Steps to reproduce the issue

Steps to reproduce the issue

1. use podman exec

$ podman exec [container name] id

Describe the results you received

Describe the results you received

[conmon:d]: exec with attach is waiting for start message from parent
[conmon:d]: exec with attach got start message from parent
DEBU[0000] Container 825dd9687d77f3e30cf74ce6e681cbcebd2798c7ea9e2d34843ccff6505f8ca1 exec session 3547ad76c81e3c55fea74298da4a3ee2162fcf69911d2489aea460cee90dd02a completed with exit code 0 
DEBU[0000] Checking status of container 825dd9687d77f3e30cf74ce6e681cbcebd2798c7ea9e2d34843ccff6505f8ca1 exec session 3547ad76c81e3c55fea74298da4a3ee2162fcf69911d2489aea460cee90dd02a 
INFO[0000] Removing container 825dd9687d77f3e30cf74ce6e681cbcebd2798c7ea9e2d34843ccff6505f8ca1 exec session 3547ad76c81e3c55fea74298da4a3ee2162fcf69911d2489aea460cee90dd02a 
DEBU[0000] Successfully removed container 825dd9687d77f3e30cf74ce6e681cbcebd2798c7ea9e2d34843ccff6505f8ca1 exec session 3547ad76c81e3c55fea74298da4a3ee2162fcf69911d2489aea460cee90dd02a 
Error: pinging container 825dd9687d77f3e30cf74ce6e681cbcebd2798c7ea9e2d34843ccff6505f8ca1 exec session 3547ad76c81e3c55fea74298da4a3ee2162fcf69911d2489aea460cee90dd02a PID 0 with signal 0: permission denied
DEBU[0000] Shutting down engines                        
INFO[0000] Received shutdown.Stop(), terminating!        PID=2130307

I updated podman version into 5.8.3 but looks same.

DEBU[0000] Successfully removed container 825dd9687d77f3e30cf74ce6e681cbcebd2798c7ea9e2d34843ccff6505f8ca1 exec session 3547ad76c81e3c55fea74298da4a3ee2162fcf69911d2489aea460cee90dd02a 
Error:  getting the process status for pid : permission denied
DEBU[0000] Shutting down engines                        
INFO[0000] Received shutdown.Stop(), terminating!        PID=2130307

Describe the results you expected

Describe the results you expected

no permission denied message

podman info output

If you are unable to run podman info for any reason, please provide the podman version, operating system and its version and the architecture you are running.


**(Now I updated the version into 5.8.3 but same Phenomenon occurs)**

host:
  arch: amd64
  buildahVersion: 1.39.0
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.12-1.el9.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.12, commit: c0564282e9befb7804c3642230f8e94f1b2ba9f8'
  cpuUtilization:
    idlePercent: 99.4
    systemPercent: 0.42
    userPercent: 0.18
  cpus: 2
  databaseBackend: sqlite
  distribution:
    distribution: rhel
    version: "9.6"
  eventLogger: journald
  freeLocks: 2040
  hostname: test-server
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 101
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 101
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.14.0-570.44.1.el9_6.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 2286780416
  memTotal: 16463163392
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.14.0-1.el9.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.14.0
    package: netavark-1.14.0-1.el9.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.14.0
  ociRuntime:
    name: crun
    package: crun-1.19.1-1.el9.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.19.1
      commit: 3e32a70c93f5aa5fea69b50256cca7fd4aa23c80
      rundir: /run/user/1001/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20250217.ga1e48a0-1.el9.x86_64
    version: ""
  remoteSocket:
    exists: true
    path: /run/user/101/podman/podman.sock
  rootlessNetworkCmd: pasta
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.3.2-1.el9.x86_64
    version: |-
      slirp4netns version 1.3.2
      commit: 0f13345bcef588d2bb70d662d41e92ee8a816d85
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.2
  swapFree: 8589930496
  swapTotal: 8589930496
  uptime: 1825h 3m 34.00s (Approximately 76.04 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /home/nombre/.config/containers/storage.conf
  containerStore:
    number: 6
    paused: 0
    running: 6
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/nombre/.local/share/containers/storage
  graphRootAllocated: 53619982336
  graphRootUsed: 27342934016
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 18
  runRoot: /tmp/storage-run-101/containers
  transientStore: false
  volumePath: /home/nombre/.local/share/containers/storage/volumes
version:
  APIVersion: 5.4.0
  Built: 1739375653
  BuiltTime: Thu Feb 13 00:54:13 2025
  GitCommit: ""
  GoVersion: go1.23.4 (Red Hat 1.23.4-1.el9)
  Os: linux
  OsArch: linux/amd64
  Version: 5.4.0

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

I checked RedHat SR and they said both the Exec UpdateStatus, and the Exec StopContainer are identified as structures that can expose me to the same problem in certain situations. Later versions reflected some improvements, and the underlying structural improvements were made in the higher version (5.6.0) but occuring same.

we have some situation to use exec from gitlab runnner to podman for reload some middleware software.

if error occurs, pipeline might be failed even if the success.

[baude]

issues with rhel should be reported to the distribution through the normal mechanisms. upstream is focused on developing the latest and future versions of podman.

i cant remember the details, but pinging used to be a somewhat privileged command. does it work as a privileged user? you also dont provide the command you are running and the image. that might also help.

[CooolRyan]

issues with rhel should be reported to the distribution through the normal mechanisms. upstream is focused on developing the latest and future versions of podman.

i cant remember the details, but pinging used to be a somewhat privileged command. does it work as a privileged user? you also dont provide the command you are running and the image. that might also help.

Do all parts of RHEL OS environment need to contact redhat?
For Podman, I'm using a regular distribution. For the current 5.8.3, I got it directly from the rpm repository and installed it.

The exact command and image are not specified because they occur the same way when all exec commands are used. Currently, images used in that environment are nginx, nginx-unprivatized, and haproxy.
The ping failure phenomenon is also found in the privileged podman environment. Logically, it seems that the same phenomenon is seen regardless of the authority because we are pinging for cases that have already ended the process.