Enhancement: Add option to delete all stopped containers in runc delete

[yzewei]

Current situation

Currently, runc delete can only remove a single container by its ID. In high-volume environments or batch container management scenarios, cleaning up stopped containers manually or one by one is cumbersome. This can also exacerbate resource contention, e.g., DBus delays or cgroup lock contention (see runc#4853).

Use case / Scenario

Direct usage of runc for batch container management.

Environments with high container churn.

Need to quickly reclaim resources from stopped containers without affecting running ones.

Proposed solution

Introduce a new flag to runc delete, e.g.:

runc delete --all-stopped
# or short form
runc delete -a
# or
runc delete -a -f

Behavior:

Deletes all stopped containers.

Skips running containers.

Cleans up metadata and cgroups of stopped containers.

Reuses the existing internal delete logic for consistency.

Benefits

Simplifies batch cleanup of stopped containers.

Avoids manual scripting to delete multiple containers.

Keeps CLI semantics consistent with single-container deletion.

Questions / Discussion Points

Are there edge cases where deleting stopped containers could interfere with ongoing operations?

Should the command output a summary of deleted containers?

[kolyshkin]

Technically you can achieve the same thing today by running something like:

runc list -q | xargs -n1 runc delete

or

for ct in $(runc list -q); do runc delete $ct; done

In both cases, all the running containers are skipped with a warning (unless --force option is supplied to runc delete, in which case all containers will be forcefully stopped and deleted).

Note that crun can do that with something like

crun delete -r .

(where . is a regular expression that matches any container name).

Maybe we should implement it, too.

[cyphar]

I was about to comment the same thing! 😅

To be honest, I prefer just using xargs. If we implement it in runc then we have to make decisions around what the error policy should be (exit on first error? collect all errors and output at the end? only output the first error but still try all containers?) and we can't provide additional guarantees such as whether we will kill containers that get created while runc delete is running so I don't really see what the benefit is to users...

The -r thing can be done using grep and more complicated things can be done with awk if necessary.

[cyphar]

Then again, maybe runc delete should accept multiple container names so you can use it with xargs more ergonomically. We still need to figure out the error policy though (probably just collecting all errors with errors.Join would work...).

EDIT: Though you could argue if runc delete foo bar baz works then runc delete -a is an obvious feature...

[yzewei]

Suggested reply:

Thanks @cyphar and @kolyshkin for the insights!

You're right that xargs or shell loops can already handle batch deletion, but I think adding native support in runc delete for multiple container IDs (e.g. runc delete foo bar baz) — or optionally -a for all stopped containers — could make scripting and error handling cleaner, especially for embedded or non-shell environments (e.g. Go wrappers, minimal container runtimes, or CI tools).

For error policy, I was thinking of something like:

Try deleting all containers sequentially.

Collect all errors with errors.Join, and print a summary at the end.

Return non-zero if any deletion fails.

That keeps behavior deterministic and user-friendly.

If the maintainers think runc delete foo bar baz is the right first step, I can work on a prototype / PR for that (and maybe later add -a as syntactic sugar).

Would that approach fit better with runc’s CLI design philosophy?