`podman wait` doesn't always distinguish "exited" "stopped" "created" as different conditions

[MalikKillian]

Issue Description

Utilizing the podman wait command doesn't always have the intended effect. According to the docs:

After all conditions are satisfied, the containers’ return codes are printed

So the command should block until the condition is met (excluding the edge case of a container not existing). There are many cases where the command will return without the condition being met (see steps to reproduce).

Steps to reproduce the issue

Steps to reproduce the issue

1. Run podman create --name init_2 busybox sh -c "sleep 15 && echo Init says Hi"
2. Run `podman inspect init_2 | grep "Status"
3. Run podman wait --condition=exited init_2 (Ctrl+C if terminal hangs)
4. Run podman wait --condition=stopped init_2 (Ctrl+C if terminal hangs)
5. Run podman wait --condition=created init_2 (Ctrl+C if terminal hangs)

Describe the results you received

The podman inspect command will show "Status": "created". Each of the other podman wait commands will return immediately without blocking.

Describe the results you expected

podman inspect will show "Status": "created". Waiting for "exited" or "stopped" should block while only the condition "created" should return immediately.

podman info output

host:
  arch: amd64
  buildahVersion: 1.41.5
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.13-1.fc42.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.13, commit: '
  cpuUtilization:
    idlePercent: 97.81
    systemPercent: 0.63
    userPercent: 1.56
  cpus: 8
  databaseBackend: sqlite
  distribution:
    codename: Deinonychus
    distribution: bluefin
    variant: bluefin-dx
    version: "42"
  emulatedArchitectures:
  - linux/arm
  - linux/arm64
  - linux/arm64be
  - linux/loong64
  - linux/mips
  - linux/mips64
  - linux/ppc
  - linux/ppc64
  - linux/ppc64le
  - linux/riscv32
  - linux/riscv64
  - linux/s390x
  eventLogger: journald
  freeLocks: 2006
  hostname: picklejuice
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
  kernel: 6.16.8-200.fc42.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 301338624
  memTotal: 7913967616
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.16.0-1.fc42.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.16.0
    package: netavark-1.16.1-1.fc42.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.16.1
  ociRuntime:
    name: crun
    package: crun-1.24-1.fc42.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.24
      commit: 54693209039e5e04cbe3c8b1cd5fe2301219f0a1
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/sbin/pasta
    package: passt-0^20250919.g623dbf6-1.fc42.x86_64
    version: |
      pasta 0^20250919.g623dbf6-1.fc42.x86_64
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1000/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: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/sbin/slirp4netns
    package: slirp4netns-1.3.1-2.fc42.x86_64
    version: |-
      slirp4netns version 1.3.1
      commit: e5e368c4f5db6ae75c2fce786e31eef9da6bf236
      libslirp: 4.8.0
      SLIRP_CONFIG_VERSION_MAX: 5
      libseccomp: 2.5.5
  swapFree: 3428323328
  swapTotal: 7913598976
  uptime: 141h 54m 44.00s (Approximately 5.88 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
store:
  configFile: /var/home/johndoe/.config/containers/storage.conf
  containerStore:
    number: 18
    paused: 0
    running: 7
    stopped: 11
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/johndoe/.local/share/containers/storage
  graphRootAllocated: 442946813952
  graphRootUsed: 205094936576
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 41
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /var/home/johndoe/.local/share/containers/storage/volumes
version:
  APIVersion: 5.6.2
  BuildOrigin: Fedora Project
  Built: 1759190400
  BuiltTime: Mon Sep 29 19:00:00 2025
  GitCommit: 9dd5e1ed33830612bc200d7a13db00af6ab865a4
  GoVersion: go1.24.7
  Os: linux
  OsArch: linux/amd64
  Version: 5.6.2

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

No response

Additional information

No response

[Honny1]

I reproduced the issue on upstream. The exited and stopped are states that have a special waiting condition, which is to wait for the container's terminal state. In this case, the container is only configured, so I am not sure how this should behave.

WDYT? How should this behave? @matejvasek @mheon

[mheon]

The Created bit is understandable. Podman's internal states do not map 1:1 to Docker's equivalents, so podman ps and podman inspect do some conversions to provide Docker-compatible output. However, we're not doing the reverse on podman wait. Internally, the container is stuck in ContainerStateConfigured, and waiting for ContainerStateCreated, which is what would happen when the container is created i the OCI runtime when it starts. Externally, we display both ContainerStateCreated and ContainerStateConfigured as Created which creates confusion. IMO, easiest fix there is to have --condition=created imply waiting for either ContainerStateCreated or ContainerStateConfigured, to match what we're outputting.

For the other two: I think we need to figure out what Docker is doing and match that. I have a feeling that the current behavior - treating any non-running container as stopped/exited - was added because Docker does the same thing... In which case the proper thing would be to document this in the manpages and retain current behavior.

[Luap99]

For the other two: I think we need to figure out what Docker is doing and match that. I have a feeling that the current behavior - treating any non-running container as stopped/exited - was added because Docker does the same thing... In which case the proper thing would be to document this in the manpages and retain current behavior.

I am pretty sure this is correct, the behavior for exited is intentional. Any non running container must mean exit right away and not hang. AFAIK there is an internal next-exit state in the docker compat API implemented via events that would likely be what the reporter wants then.

The wait condition names in the docker API certainly make more sense https://docs.docker.com/reference/api/engine/version/v1.51/#tag/Container/operation/ContainerWait
not-running, next-exit, removed.

so exited matches not-running basically