Why does "podman generate systemd" generate "Type=forking" (when run without --new)?

[eriksjolund]

"systemd generate systemd" (without --new)

podman generate systemd without --new generates services with Type=forking

test 1

$ podman run --name test1 -d docker.io/library/nginx
d36d96292cffde340a42cc7e0f115874dfe351b47d873cbc24cc39bb63363449
$ podman generate systemd --name test1 | grep Type=
Type=forking
$

test 2

$ podman run --name test2 --sdnotify=conmon  -d docker.io/library/nginx
04ec43f0d8688eb60beb29bb0f3c18a673d329ad71d0eda7ebef278de0e05766
$ podman generate systemd --name test2 | grep Type=
Type=forking

test 3

$ podman run --name test3 --sdnotify=container  -d docker.io/library/nginx
dc4fa293ec6d0ff32bcdaaa7abafb042d3f8471485c4cdbfc6ddfdf8be58c374
$ podman generate systemd --name test3 | grep Type=
Type=forking

"systemd generate systemd" (with --new)

podman generate systemd with --new generates services with Type=notify

$ podman generate systemd --name test1 --new | grep Type=
Type=notify
$ podman generate systemd --name test2 --new | grep Type=
Type=notify
$ podman generate systemd --name test3 --new | grep Type=
Type=notify

Discussion

Could it be that Type=forking was chosen because of the default value for the
for the podman run option --sdnotify? The default value is currently container.

That would explain the design choice for test 1 but not for test 2 and test 3.

I'm starting to think that the default value for --sdnotify should be changed from container to conmon.

It would then be possible for systemd generate systemd to generate Type=notify for test 1, test 2, test 3.

[eriksjolund]

I found a quote from the PR
#10557
that added Type=notify support for --new:

"but it doesn't really work well since we're competing with the default
sdnotify mode set during container creation."

[vrothberg]

Yes, that is it. With podman start we cannot control the sdnotify-mode of the container.

[mheon]

@vrothberg PTAL