Description of problem: An active podman process is unable to be cleanly stopped by systemd reboot/shutdown, and thus has to be killed after the 2min grace period expires. How reproducible: Always. Steps to Reproduce: 1. `podman run -it docker.io/library/busybox` 2. Inside the container: `sleep infinity` 3. Reboot the system Actual results: Shutdown procedure hangs for ~2 minutes because podman can't be stopped. Then podman is killed and shutdown is complete. Expected results: Podman is terminated gracefully like any other process and system reboots immediately. Additional info: Related toolbox bug, caused by this one: https://bugzilla.redhat.com/show_bug.cgi?id=2081664
Upstream issue: https://github.com/containers/podman/issues/14531
Quoting from the upstream comment [1]: I don't think there is much Podman can do. sleep in busybox does not seem to respond to SIGSTOP, so systemd has to wait for the grace period to end until it can kill the process. [1] https://github.com/containers/podman/issues/14531#issuecomment-1149879040
I believe that podman run/start should catch SIGTERM and then execute podman stop on its pods/containers. This would cause the containers to exit properly or exit after 10 seconds. This might be a slight deviation from Docker in some corner cases, but I believe this is the right behaviour. Especially if a container is running with a STOP_SIGNAL that is different then SIG_TERM. In the common case where a container is sending SIG_TERM, there is no change except the container gets killed after 10 seconds. In the case where STOP_SIGNAL is set then the container has a chance to close cleanly (systemd based containers for example). The only case that really changes is a corner case where user expects SIGTERM of Podman to send SIGTERM to container, when the container is not useing STOP_SIGNAL==SIGTERM. In this case users could just call `podman kill --signal SIGTERM $CTR` From a user point of view, I think this is the most user friendly way to handle this.
I think this was fixed upstream: https://github.com/containers/podman/issues/14531 https://github.com/containers/podman/pull/17025
FEDORA-2023-431945fc20 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-431945fc20
FEDORA-2023-998dbd3b79 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-998dbd3b79` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-998dbd3b79 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-998dbd3b79 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.