Skip to content

libpod: add next-exit/not-running/removed wait conditions (fixes #27423)#28976

Open
dcermak wants to merge 1 commit into
podman-container-tools:mainfrom
dcermak:container-wait
Open

libpod: add next-exit/not-running/removed wait conditions (fixes #27423)#28976
dcermak wants to merge 1 commit into
podman-container-tools:mainfrom
dcermak:container-wait

Conversation

@dcermak

@dcermak dcermak commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

podman wait --condition=exited (and =stopped) returns immediately with exit code 0 for a container that has been created but never started. This matches Docker's not-running default semantic, a container that has never run is, by definition, not running. But that leaves users with no way to express "block until the container has actually been started and has exited"

Expose the Docker-style condition aliases at the libpod wait API and CLI:

  • next-exit: subscribe to died events and block until the container's next exit, regardless of current state. Returns the real exit code
  • not-running: match any non-running sub-state. Delegates to WaitForExit so the real exit code (or 0 for a never-started container) is returned
  • removed: block until the container has been removed, returning the recorded exit code

Fixes: #27423

Checklist

Ensure you have completed the following checklist for your pull request to be reviewed:

  • Certify you wrote the patch or otherwise have the right to pass it on as an open-source patch by signing all
    commits. (git commit -s). (If needed, use git commit -s --amend). The author email must match
    the sign-off email address. See CONTRIBUTING.md
    for more information.
  • Referenced issues using Fixes: #00000 in commit message (if applicable)
  • Tests have been added/updated (or no tests are needed)
  • Documentation has been updated (or no documentation changes are needed)
  • All commits pass make validatepr (format/lint checks)
  • Release note entered in the section below (or None if no user-facing changes)

Does this PR introduce a user-facing change?

- add next-exit, not-running & removed wait conditions to podman wait

@github-actions github-actions Bot added the kind/api-change Change to remote API; merits scrutiny label Jun 19, 2026

@Honny1 Honny1 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I have some comments.

Comment thread libpod/container_api.go
}()
}

if waitForNextExit {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these wait logics are implemented in compat API pkg/api/handlers/utils/containers.go (waitNextExit, waitNotRunning, waitRemoved). I would reuse them.

// regardless of the container's current state. This differs from
// "exited"/"stopped", which return immediately for a container that
// has never been started.
ContainerWaitConditionNextExit = "next-exit"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use ContainerStatus type?

Comment thread test/e2e/wait_test.go Outdated
…an-container-tools#27423)

`podman wait --condition=exited` (and `=stopped`) returns immediately with exit
code 0 for a container that has been created but never started. This matches
Docker's `not-running` default semantic, a container that has never run is, by
definition, not running. But that leaves users with no way to express "block
until the container has actually been started and has exited"

Expose the Docker-style condition aliases at the libpod wait
API and CLI:
* next-exit: subscribe to died events and block until the container's next exit,
             regardless of current state.  Returns the real exit code
* not-running: match any non-running sub-state. Delegates to WaitForExit so the
               real exit code (or 0 for a never-started container) is returned
* removed: block until the container has been removed, returning the recorded
           exit code

Fixes: podman-container-tools#27423

Co-authored-by: Jan Rodák <hony.com@seznam.cz>
Signed-off-by: Dan Čermák <dcermak@suse.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind/api-change Change to remote API; merits scrutiny

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

2 participants