Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
While i was playing around with podman I wondered why it is that systemd startup is so overcomplicated.
My problem is that I can either start single containers by writing a systemd init script for each container or i can use generate, which i have to redo each and every time a container upgrades.
So why is it that I cant just write an systemd template like so:
Once I have configured my pods I can just start them by using: systemctl enable pod@foo ; systemctl start pod@foo
It turns out that systemd needs to stay attached to one container to detect if the service is running, therefore I wrote a little workaround like this:
and modified pod@.service:
My proposal for an elegant solution would be to add a parameter --attach_to_infra to podman pod start which attaches STDIN and STDOUT to the Infra container. And to add pod@.service to the upstream code.
Hi @vrothberg yes I have looked into generate if that was not clear from my second paragraph.
First of all it generated all unit files cat together on stdout, leaving me up with an editor to tear them apart. (i know i can do that with a script, too)
Secondly, those init scripts are pinned to the container-ids and those are changing weekly if not more frequently as containers are immutable. Which means I have to tear down the old container unit files and replace them with the new ones in the process.
Not to mention that the unit file names change with the container IDs.
You can now esimate the lines of code a user/sysadmin has to implement to render those service unit files whenever they need to be regenerated. It is probably even easier to write template them from scratch than to use podman generate systemd at all.
As for the restart policy. podman has one. During container creation you can set --restart=always causing podman to monitor if a container has crashed. This works more than sufficient for all of my current use cases. I can still write my own units to do dependency management if necessary but that is getting much easier with --attach_to_infra parameter as suggested.
There's a CLI flag
That's a snippet of a service pointing to such a
The process seems straight forward to me:
Whenever a pod/container is updated, we can run
One service file for a pod is not sufficient for systemd to know if the pod is running or not. Imagine a service-critical container of the Pod fails. With only one service file, systemd does not know about the failing container and can't enforce the restart policy. A
Oh I somehow overlooked the --file option.
tbh i did not understand immediately why using --restart=always is not sufficient, but you are probably referring to those conmon processes (one for each container) I guess if one of those fails without warning it can cause trouble.
Anyway, having the pid file accessible under the container name sounds very good to me. :)
I wonder if adding a container name -> ID symlink somewhere might be worthwhile - an easy filesystem way of identifying the specific container associated with a name... Probably not worth it unless we're going to expose a lot more via the filesystem than we do now, though.
I'd like to add another potential lovely usecase that would be enabled by being able to just straight run from systemd.
Ignoring the content of the launch itself, what it allows is running ephemeral containers as system services.
This pretty much allows me to run these services mostly hands-off, no need to update the units every time i update it or anything like that.
I've had this working somewhat with docker and using this tool, https://github.com/ibuildthecloud/systemd-docker, but it was always flaky.
One iffy problem with running podman generate is that its a bit iffy when you wish to add some customizations on top.
One idea that comes to mind is to somehow use
The biggest problem is that starting the container through systemd hangs both that invocation of systemctl and podman until some magical timeout gets hit.
Will drop a few more comments as i figure things out.