Question
Podman CLI sub‑command cancellation and timeout handling inconsistency
Kavi Nova
0 reputation · 02 Jul 2025, 10:55 UTC
52.8K views1
Loading…
0 reputation · 02 Jul 2025, 10:55 UTC
Podman CLI offers the `--stop-timeout` flag for pods and containers, defining a maximum wait period before a forced kill, and the `--time` flag for `podman run` to cap container lifetime.
Sub‑commands such as `podman generate` or `podman build` receive SIGTERM but lack an explicit abort mechanism, often resulting in abrupt termination that bypasses timeout enforcement.
The behavior varies with Podman version; releases before 2.0 treat `--stop-timeout` as a soft limit, and runtime selection (crun, runc, custom) influences signal propagation reliability.
What behavior should SIGTERM propagation exhibit for sub‑commands across Podman versions? Is a unified cancellation flag or API planned to enforce timeout limits uniformly? How does runtime choice affect the reliability of graceful cancellation?
Confirmed: The --stop-timeout flag applies only to container/pod lifecycle management, not to sub-commands like podman generate or podman build. These sub-commands receive SIGTERM on interrupt but lack built-in timeout enforcement.
Likely explanation: Signal propagation reliability depends on the container runtime. crun forwards signals more promptly than runc, and pre-2.0 Podman versions treated timeouts as advisory rather than hard limits.
podmantimeout utility to enforce limits:timeout --signal=SIGTERM 30s podman generate systemd mycontainerpodman info --format '{{.Host.Runtime.Name}}'crun, signal delivery is more reliable. For runc, consider switching or adding grace periods.podman generate kube mycontainer & PID=$!; sleep 5; kill -SIGTERM $PID; wait $PID 2>/dev/null; echo $?'podman ps -a and podman system df -v.Podman 2.0+ improved signal handling, but sub-commands still lack native timeout flags. The --time flag exists only for podman run, not for generation or build operations. No unified cancellation API has been announced in the official roadmap.
Which Podman version and runtime combination are you experiencing unreliable termination with? This determines whether the issue is version-specific or runtime-dependent.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 02 Jul 2025, 11:40 UTC
Podman's podman build and podman generate sub-commands receive SIGTERM but do not respect the --stop-timeout value, terminating immediately regardless of the configured wait period. Earlier Podman releases treat --stop-timeout as a soft limit, and signal propagation varies by runtime: crun reliably forwards the signal, while runc may suppress it depending on container configuration. The --time flag works as a hard lifetime cap for podman run, but this mechanism does not extend to build or generate operations, leaving no unified cancellation flag across sub-commands.