Bug 2149642 - systemd presets request - podman-restart
Summary: systemd presets request - podman-restart
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-11-30 13:48 UTC by Daniel Walsh
Modified: 2023-01-13 19:11 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2023-01-09 20:48:47 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github containers podman pull 17110 0 None open podman-restart: Drop `network-online.target` dependency 2023-01-13 19:10:59 UTC

Description Daniel Walsh 2022-11-30 13:48:53 UTC
Podman allows the configuration of restart containers. 

# podman run --restart=always nginx

When the system reboots, users expect that this container will be running. In Docker this happens because the user enables the docker service, to create the container in the first place. When the docker daemon starts, it checks to see if their are any containers configured with restart, then it starts them.

With Podman we rely on systemd an the podman-restart service to handle this. Thus we would like podman on installation to configure the podman-restart service to run at boot by default.

When the system boots, systemd launches podman-service unit file which execs 

/usr/bin/podman start --all --filter restart-policy=always

This service then runs through the podman database looking for containers with restart=always and starts them. Since this is a oneshot unit file, podman exits and is never run again.

* Does the service require post-rpm-installation configuration in order to be useful (for example, does it need manual edits to a configuration file)?

No,

* Does the service listen on a network socket for connections originating on a separate physical or virtual machine?

No.

* Is the service non-persistent (i.e. run once at startup and exit)?

Yes it only runs at boot, checks if there are any containers to start, starts them then exit.  Never runs again until next reboot.

* What is the exact name (or names) of the systemd unit files to be enabled?

/usr/lib/systemd/system/podman-restart.service

* Is this request for all Fedora deliverables or only for some Editions (list them)?

All

Comment 1 Jonathan Lebon 2023-01-13 18:17:16 UTC
This service pulls in network-online.target. As documented in https://systemd.io/NETWORK_ONLINE/, network-online.target in general should be avoided in favour of more dynamic approaches. It's unfortunate to have an enabled-by-default service using it.

Since `--restart=always` is documented as "retrying indefinitely", it seems reasonable to instead have it automatically keep retrying if networking isn't yet up. Another approach would be for podman to only enable this service when a `--restart=always` container is actually started (and disabled if the last `--restart=always` container is removed).

Comment 2 Dusty Mabe 2023-01-13 18:42:57 UTC
For the record, we've been bit by having `network-online.target` enabled in FCOS in the past so we wrote a test that now fails if it gets pulled in by default, which is why we ended up here.

https://github.com/coreos/fedora-coreos-tracker/issues/1380#issuecomment-1382221004

Comment 3 Colin Walters 2023-01-13 18:50:02 UTC
A slightly more efficient approach here would be to:

- Change podman to have a file /var/lib/containers/autostart-enabled that exists iff an autostart container exists
- Have the systemd unit use ConditionPathExists=/var/lib/containers/autostart-enabled

This way we shave off loading and executing podman and scanning all containers (right?) on every boot even for people who don't use this feature

Comment 4 Jonathan Lebon 2023-01-13 18:54:44 UTC
> - Have the systemd unit use ConditionPathExists=/var/lib/containers/autostart-enabled

This won't work because systemd doesn't consider ConditionPathExists when setting up the transaction. Conditions are evaluated right before the service is scheduled to start IIRC. We use generators to work around this in our code, which would work here too of course.

Comment 5 Colin Walters 2023-01-13 18:59:46 UTC
Right sorry, I was not trying to directly solve the Requires=network-online.target problem.  Why would that even be required?

Comment 6 Daniel Walsh 2023-01-13 19:03:57 UTC
Probably a cut and paste from an existing PR.

I guess they wanted to start the service as soon as the network is up.

Please open a PR to how you would like it to look.

Comment 7 Colin Walters 2023-01-13 19:11:00 UTC
Yeah agree, time to stop writing text in bugzilla and write code in a PR.  Filed https://github.com/containers/podman/pull/17110


Note You need to log in before you can comment on or make changes to this bug.