Add podman system boot for installing services

[UebelAndre]

/kind feature

Description

Add a podman system boot command that installs a systemd service to run a pod on startup as the user who installed the service.

This is a followup of containers/podman-compose#254 where I had requested a feature of podman-compose to install systemd services for a pod via some built in command. The motivation here is that I've noticed users all installing systemd services for their pods in different ways making it difficult to manage. @rhatdan and @mheon discussed adding a podman system boot as a solution to the linked issue from podman-compose. I'm hoping opening the issue here (as suggested by @rhatdan) is the right thing to do to move this forward.

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

AWS/VirtualBox/physical

[rhatdan]

This should not be that hard to do.

Basically you need a new command

podman system boot

Which will use libpod looking for stopped containers that should be started at boot time and then start them.

Second part would be to create a systemd service file that runs podman system boot at boot time, once.

[boaz0]

@rhatdan mind if I work on it?

[rhatdan]

I never mind free labor.

[vrothberg]

Can you summarize what the command should do? It's not obvious to me what the problem is and how the solution should look like.

[UebelAndre]

My request is that it handles installing and enabling systemd services that will restart pods on system boot as the users who own/made them. Effectively, I want to be able to run podman system boot $POD and have any existing services for that pod get cleaned up and replaced with the new service. This way users aren't leaking resources by failing to cleanup pods and they aren't installing hand written service files which all have slightly different behavior when they should be the same.

[vrothberg]

Thanks for clarifying!

We've had discussion around installing systemd unit files before, and I really don't like it. It is something that systemctl IMHO should handle (e.g., a hypothetical systemctl install). I think that installing and managing these files is out of Podman's scope, and I don't want Podman to turn into a manager of systemd unit files. I completely understand the desire to have that feature but I prefer drawing the lines early on to not open the door for other, yet related requests, such as managing K8s yaml or Ansible.

Looking at the command, the naming would be a bit unfortunate as podman generate would generate these systemd files, and podman system would manage them.

[vrothberg]

@rhatdan @mheon, can we re-discuss?

[UebelAndre]

Would love to see another discussion on this. I understand the desire to not have podman manage a bunch of external systems but I feel this interaction with systemd makes sense. This has been the biggest point of frustration in switching from Docker where containers could be easily configured to start on boot. Because there is no systemctl install users have hand authored ways of managing their services which have primarily lead to bugs and unexpected behavior. Ultimately, all I'm after is a consistent and "canonicalized" way to configure a pod to restart on boot and handle edge-cases of installing/uninstalling services.

[vrothberg]

Did you reach out to the systemd folks? I have no idea if that was already discussed there.

@msekletar may know :)

[UebelAndre]

I haven't. I would like to know see your discussion here first before I go open this request in yet another repo. So far you're the only person who's voiced that this isn't a good idea. To my knowledge there are already people working on it and I would expect after a conversation with other maintainers that either the implementation efforts continue or this is closed with a link to the new request in systemd.

[mheon]

This sounds very different from what I understood the intent of system boot was... The understanding I had was that this was a simple shim to implement a counterpart to Docker's restart policy handling of reboots - a container with --restart=always but no systemd unit should be restarted on boot, to be handled by a systemd oneshot unit invoking a Podman command to start relevant containers. It doesn't really fit with our overall scheme of using Systemd units to handle restart, but it is a fairly significant feature in Docker we'd love to have a counterpart to. @rhatdan Can you confirm?

[UebelAndre]

Sorry about my lack of clarity. Ultimately I'm trying to address some pain in switching from docker. I'd originally posted this in podman-compose because I saw it as a unique interaction between podman and systemd. My expectations were that some command there would be able to:

1. Create a pod
2. Generate a service file
3. Install and enable the service (requires root for install but service would otherwise run restart pods as rootless user who created it)
4. Updating/recreating the pod updates/recreates the service file

podman-compose mostly works with the uses of docker-compose I've come across so having this kind of functionality would effectively satisfy the need for docker and make switching less painful and time consuming.

[vrothberg]

Sorry about my lack of clarity. Ultimately I'm trying to address some pain in switching from docker. I'd originally posted this in podman-compose because I saw it as a unique interaction between podman and systemd. My expectations were that some command there would be able to:

1. Create a pod

2. Generate a service file

3. Install and enable the service (requires root for install but service would otherwise run restart pods as rootless user who created it)

Why is root required to install the service?
Non-root services can be installed in $HOME/.config/systemd/... and be managed with systemctl --user.

4. Updating/recreating the pod updates/recreates the service file

I think this a common work flow when using podman generate systemd that can easily be scripted:

podman pod create --name $NAME ...
podman generate systemd --new --files $NAME
mv *.service $HOME/.config/systemd/user
systemctl --user daemon-reload
systemctl --user start pod-$NAME.service

Is that matching what you have in mind?

[vrothberg]

Quick summary from a chat with @mheon and @rhatdan:

The original idea was to facilitate restarting containers on boot. That's something Podman does not yet handle. We refined the idea a bit and want to do the following:

• Ship a systemd service (similar to podman-auto-update.service) that package managers would install on the system.
• This systemd service (oneshot) would on boot (re)start the containers that are configured accordingly.
• The restarting would happen via podman start. To do that podman start needs two new things:
  • A --all flag to restart all containers.
  • A --filter which allows to filter for specific attributes of the containers. For instance, a filter to match a specific restart policy.

@boaz0, are you cool with this approach?

[boaz0]

@vrothberg sure. Looks good to me. I will update my PR.

[rhatdan]

That sounds good to me as well.

[vrothberg]

@vrothberg sure. Looks good to me. I will update my PR.

Thanks, @boaz0 !

[github-actions]

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

[rhatdan]

Still in holding pattern. We would like to really push this forward once podman 3.0 is released.

[github-actions]

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

[rhatdan]

@boaz0 Do you have time to work on this, or should we take it over?

[boaz0]

Part of it is ready for review. The other part is going to be pushed as PR by the end of the day.

[github-actions]

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

[boaz0]

Tonight I am going to push updates... remove stale tag. 🙏