Systemd managed pods that don't kill all containers when one dies

[nivekuil]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Currently podman generate systemd for a pod includes a Requires= for each container service. This means when one container dies, the entire pod service is considered failed and will kill every other container in the pod. Not sure if this is the intended behavior but it is not ideal for robustness. An easy workaround is to change this to Wants=. I also wonder if this functionality should be done in the reverse direction with RequiredBy= or WantedBy= instead, which matches the semantics of podman create --pod ...

[rhatdan]

@vrothberg PTAL

[vrothberg]

Thanks for reaching out, @nivekuil. Can you share a reproducer?

From the systemd.unit man page:

If this unit gets activated, the units listed will be activated as well. If one of the other units fails to
activate, and an ordering dependency After= on the failing unit is set, this unit will not be started. Besides,
with or without specifying After=, this unit will be stopped if one of the other units is explicitly stopped.

That sounds like a sane behavior to me. If one of the container units fails to start, I don't want to pod unit to be marked as active but to reflect the error.

Your comment suggests that the pod unit fails if container unit starts successfully but then fails at some later point. Do I read it correctly?

[nivekuil]

Your comment suggests that the pod unit fails if container unit starts successfully but then fails at some later point. Do I read it correctly?

yes

That sounds like a sane behavior to me. If one of the container units fails to start, I don't want to pod unit to be marked as active but to reflect the error.

This actually doesn't reflect how podman works without systemd. For example if I do

podman create --entrypoint=/foo/bar --name=bad --pod=test docker.io/nginx

and then podman pod start test it will print an error but the pod will be active and its other containers will be running.

[vrothberg]

This actually doesn't reflect how podman works without systemd.

I think the point of having pods in systemd is to have such kind of (more robust) behavior. If a container fails that is part of a larger service, the service should be restarted IMHO.

To match Podman's behavior you could try with podman generate systemd --restart-policy=none. Does that match what you are looking for?

[nivekuil]

No, the point is to have robust services such that container uptime is as high as possible.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@vrothberg any new thoughts on this?

[kdknigga]

I agree with @nivekuil , having the pod-X unit Wants= the container units makes sense. Or, even better, make the choice between the two behaviors available via an option to podman generate systemd like --restart-policy.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@vrothberg any update on this?

[Ramblurr]

We're also running into this problem. It is quite unexpected.

[vrothberg]

Thanks for the ping(s). I'll take a stab at it.