generate systemd: custom stop signal

Commit 9ac5267598c3 changed the type of the generated systemd units from
forking to notify.  Parts of these changes was also removing the need to
pass any information via the file system (e.g., PIDFILE, container ID).
That in turn implies that systemd takes care of stopping the container.

By default, systemd first sends a SIGTERM and after a certain timeout,
it'll send a SIGKILL.  That's pretty much what Podman is doing, unless
the container was created with a custom stop signal which is the case
when the --stop-signal flag was used or systemd is mounted.

Account for that by using systemd's KillSignal option which allows for
changing SIGTERM to another signal.  Also make sure that we're using the
correct timeout for units generated with --new.

Fixes: #11304
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>

1 files changed, 13 insertions, 0 deletions

diff --git a/test/system/250-systemd.bats b/test/system/250-systemd.bats
index ee951ff21..37e5fa2f9 100644
--- a/test/system/250-systemd.bats
+++ b/test/system/250-systemd.bats
@@ -125,4 +125,17 @@ function service_cleanup() {
     service_cleanup
 }
 
+@test "podman generate systemd - stop-signal" {
+    cname=$(random_string)
+    run_podman create --name $cname --stop-signal=42 $IMAGE
+    run_podman generate systemd --new $cname
+    is "$output" ".*KillSignal=42.*" "KillSignal is set"
+
+    # Regression test for #11304: systemd wants a custom stop-signal.
+    run_podman rm -f $cname
+    run_podman create --name $cname --systemd=true $IMAGE systemd
+    run_podman generate systemd --new $cname
+    is "$output" ".*KillSignal=37.*" "KillSignal is set"
+}
+
 # vim: filetype=sh