Podman: Use `--new` flag when generating systemd units for containers in pod

[xcffl]

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

/kind feature

Description

According to https://github.com/containers/libpod/pull/4861, we should not create cgroup under systemd. Otherwise there will be
Mar 25 10:29:23 fedora systemd[1923]: container-nginx_nginx-proxy_1.service: Found left-over process 740015 (fuse-overlayfs) in control group while starting unit. Ignoring. Mar 25 10:29:23 fedora systemd[1923]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. Mar 25 10:29:23 fedora systemd[1923]: container-nginx_nginx-proxy_1.service: Can't open PID file /run/user/1000/overlay-containers/7ad6199f207f660f765c57b3607f47a996878233b5083e9a110d9139a618d806/userdata/conmon.pid (yet?) after start: Operation not permitted
and the pod will keep restarting forever.

Also, new functions such as podman auto-update only works for containers with --new.

I don't see any reasons not to use the same behavior when creating container systemd units in pod

Steps to reproduce the issue:

1.

2.

3.

Describe the results you received:

Describe the results you expected:

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

(paste your output here)

Output of podman info --debug:

(paste your output here)

Package info (e.g. output of rpm -q podman or apt list podman):

(paste your output here)

Additional environment details (AWS, VirtualBox, physical, etc.):

[vrothberg]

Please open one issue per bug/request. Otherwise, it's hard to track them.

According to #4861, we should not create cgroup under systemd.

This should already be fixed as we're not creating cgroups for conmon anymore.

I don't see any reasons not to use the same behavior when creating container systemd units in pod

Well, we're always welcoming contributions!

It's on the todo-list but does not have a high priority at the moment. Similar to what we're doing for containers with the --cidfile, we need a --podidfile and --pidfile for podman-create to save the pod ID/name and the ID of the infra-container (pidfile). Once that's done, we can support --new for Pods as well.

Supporting auto updates for Pods will require us to make the auto-update code smarter and group containers by Pods but that's something we can tackle after --new works for Pods.

[xcffl]

This should already be fixed as we're not creating cgroups for conmon anymore.
Well #4861 's approach only works for containers but not pods, because it made it by appending an parameter to the generated systemd file, which will not be appended when generating systemd service for pods:

https://github.com/containers/libpod/blob/45e7cbfef65d0379af19264c5fa90e1ae9ccb74a/pkg/systemd/generate/systemdgen.go#L174

Please open one issue per bug/request. Otherwise, it's hard to track them.

Well it's actually derived from https://github.com/containers/libpod/issues/5541 and from my perspective there is not a good workaround for https://github.com/containers/libpod/issues/5541 due to the cgroup issue.

It's on the todo-list

That's great. Then I may find a time to improve this.

[github-actions[bot]]

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

[vrothberg]

Removing the "good first issue" label as I don't think it is. It's fairly complex to get it right (especially considering the dependency graph).

[xcffl]

As v2.0 is going to support Docker API, probably podman auto-update will be obsoluted.

The problem still exists if podman keeps handling cgroups in the same strategy. As of the dependency graph, I think systemd handles this well. Maybe that would be helpful.

[vrothberg]

As v2.0 is going to support Docker API, probably podman auto-update will be obsoluted.

Can you elaborate on that? I don't see an immediate link between the rest API and auto-updates.

The problem still exists if podman keeps handling cgroups in the same strategy. As of the dependency graph, I think systemd handles this well. Maybe that would be helpful.

Yes, systemd handles dependencies really well. Podman is already making use that when generating unit for pods. It's a bit trickier with --new though.

[xcffl]

Can you elaborate on that? I don't see an immediate link between the rest API and auto-updates.

I'm not so sure about what the API will be? If it means the support of unix:///var/run/docker.sock, we'll be able to use watchtower (an updater daemon container) later, which is great :laughing:

It's a bit trickier with --new though.

Agree. Maybe a better solution is to allow podman-compose to create systemd units. Then there will be no problem (by which I mean what we can do on docker can we do on podman then as well).

[floating-cat]

Hi,
I use the podman auto-update in my several servers and I really like it.
Though I am also fine to use the Watchtower instead of it if the Podman team thinks the Watchtower would be a better choice in the long run. Otherwise, I am very looking forward to seeing the support for the --new after the Podman v2.

[rhatdan]

No we would like to make this an integrated part of Podman.

[xcffl]

No we would like to make this an integrated part of Podman.

That's the best. It wasn't ported so I thought you abandoned auto updates.

[xcffl]

As a temperary workaround, one can use the following  script to start containers by systemd directly, instead of pods (requires jq installed):

NAME=${PWD##*/}

rm -rf ./systemd

mkdir systemd
cd systemd

# Only generate systemd services for containers
CONTAINERS=$(podman pod inspect $NAME | jq -r ' . | .Containers[].Id ')
for CON in $CONTAINERS
do
        echo "podman generate systemd --new --files $CON"
        podman generate systemd --new --files $CON &
done

cp *.service ~/.config/systemd/user/

# Stop pod but keep it
podman pod stop $NAME

# Start all containers in the pod
for CON in $CONTAINERS
do
    # remove all (non-manager) containers in the pod as a workaround for creating new containers each time
        podman rm $CON
        echo "sudo systemctl enable container-$CON"
        systemctl --user enable container-$CON --now &
done

[rhatdan]

This is now being worked on in https://github.com/containers/libpod/issues/5605

[xcffl]

Just to make sure... I notice that podman apis have a /libpod prefix, meaning it's not compatible with those who now support docker. Is the incompatibility intended or not? Since we mentioned leveraging watchtower here before. @rhatdan

[rhatdan]

We support both traditional Docker APIs in our compatibility mode and the newer libpod mode for some of the more advanced features of Podman.

Search for "compat" on https://docs.podman.io/en/latest/_static/api.html

[vrothberg]

With #5605 being merged, we can close the issue. Thanks for the input!