podman: Improve handling of "stopping" container removal in remove_container()
Cherry-picked from e3ba7ba866d2d2cd7b1fe37a111445dc3c95182d

Signed-off-by: Pooja Senthil Kumar <pooja.senthil.kumar@oracle.com>
Reviewed-by: Laurence Rochfort <laurence.rochfort@oracle.com>
---
diff -uNr a/heartbeat/podman b/heartbeat/podman
--- a/heartbeat/podman	2025-02-05 16:42:14.853652067 -0800
+++ b/heartbeat/podman	2025-02-05 16:44:31.256704873 -0800
@@ -254,6 +254,13 @@
 	ocf_run podman rm -v $CONTAINER
 	rc=$?
 	if [ $rc -ne 0 ]; then
+		if [ $rc -eq 2 ]; then
+			if podman inspect --format '{{.State.Status}}' $CONTAINER | grep -wq "stopping"; then
+				ocf_log err "Inactive container ${CONTAINER} is stuck in 'stopping' state. Force-remove it."
+				ocf_run podman rm -f $CONTAINER
+				rc=$?
+			fi
+		fi
 		# due to a podman bug (rhbz#1841485), sometimes a stopped
 		# container can still be associated with Exec sessions, in
 		# which case the "podman rm" has to be forced
@@ -508,8 +515,8 @@
 		# but the associated container exit code is -1. If that's the case,
 		# assume there's no failure and continue with the rm as usual.
 		if [ $rc -eq 125 ] && \
-		   podman inspect --format '{{.State.Status}}:{{.State.ExitCode}}' $CONTAINER | grep -wq "stopped:-1"; then
-			ocf_log warn "Container ${CONTAINER} had an unexpected stop outcome. Trying to remove it anyway."
+		   	podman inspect --format '{{.State.Status}}:{{.State.ExitCode}}' $CONTAINER | grep -Eq '^(exited|stopped):-1$'; then
+			ocf_log err "Container ${CONTAINER} had an unexpected stop outcome. Trying to remove it anyway."
 		else
 			ocf_exit_reason "Failed to stop container, ${CONTAINER}, based on image, ${OCF_RESKEY_image}."
 			return $OCF_ERR_GENERIC