How to replace the "podman generate systemd" command since its deprecated

[Pamalosebi]

The description states simply "Use Quadlet for running containers and pods under systemd.".
tldr: Please tell me how to replace "podman generate systemd" in my environment.

In my current setup, I have Podman installed on several hosts, along with podman-compose. The entire setup runs under a rootless user configuration, with all containers operating as rootless as well. I have created a podman-compose.yml file fitting to my use cases and requirements.
Once everything is configured properly and the containers are running smoothly with podman-compose, I use the following script to generate systemd service files for the containers created through podman-compose:

#!/bin/bash

# The directory for systemd user services
SYSTEMD_USER_DIR=$HOME/.config/systemd/user

# Create the systemd user services directory if it doesn't exist
mkdir -p "$SYSTEMD_USER_DIR"

# remove all old entries
rm -rf "$HOME"/.config/systemd/user/*

# Get the names of the running Podman containers
CONTAINER_NAMES=$(podman ps -a --format "{{.Names}}")

# Generate and overwrite the systemd files for each container
for CONTAINER_NAME in $CONTAINER_NAMES; do
  echo "Generating systemd file for $CONTAINER_NAME"

  # Generate the systemd service file for the Podman container
  podman generate systemd -t 5 "$CONTAINER_NAME" > "$SYSTEMD_USER_DIR"/"$CONTAINER_NAME".service

  # Reload the systemd daemon
  systemctl --user daemon-reload

  # Enable the new service
  systemctl --user enable "$CONTAINER_NAME".service
done

I've been using Podman for a long time, especially appreciating the "podman generate systemd" command. The last update seem to move away from this key feature. I checked out Quadlet, but it doesn’t match the functionality and flexibility I'm used to. I don't want to write for every single container a Quadlet file and maintain it.

I really like Podman, but the change might force me to consider switching to something else... maybe Docker. I'm open to Quadlet or other alternatives if they can cover the same ground. Is there something I've missed or another way to maintain the functionality I need within Podman's ecosystem? Can I automatically create Quadlet files somehow ?

[eriksjolund]

Maybe the command podlet could be useful?
https://github.com/k9withabone/podlet
It looks like podlet can transform a podman run command into a container unit.

[groovyman]

Thank you, but in this case you should give the maintainer of Fedora an hint, that they should also ship this tool in their Fedora F39 distribution. Currently, there is a gap due to the removal of the absense of the podman generate systemd command.

[Pamalosebi]

Thank you @eriksjolund

This would sound promising:

Convert a (docker) compose file to:
Multiple quadlet files

But then a little further down they state:

When converting compose files, not all options are supported by podman/quadlet. This is especially true when converting to a pod as some options must be applied to the pod as a whole. If podlet encounters an unsupported option an error will be returned. You will have to remove or comment out unsupported options to proceed.

I would have to put a lot of time and effort in this now... while it was super simple and reliably before.

Actually we wanted to discuss using Podman for my business projects. We've begun some test projects with it, but I'll have to stop these efforts next week. I just don't see how I could manage a big number of containers (and how they are geared together) using Quadlet files.

[rhatdan]

We are not suggesting that you drop compose and move to quadlet, we are suggesting that for standard containers running under systemd, that people use quadlet.

You seem to have a unique case here that we would like to discuss perhaps at a community cabal meeting.
@vrothberg WDYT?

[vrothberg]

I miss exact requirements. The description is very high level. @Pamalosebi, can you elaborate what is missing exactly?

I personally think that writing a .container file once is less work than creating a container manually and then scripting around podman-generate-systemd to generate the units. But I may be missing something crucial in your use case.

[Pamalosebi]

Quadlet requires users to create and manage multiple files (.container, .network, .volume) for each container.
This becomes much more complex and difficult to manage, especially if you have a large number of containers.
This also affects versioning and updates. A single compose-file previously made project tracking straightforward.

I am familiar with podman generate and the transition and effective use of quadlets will take time and testing.

Then one of the first points in the documentation is that when a quadlet is started, Podman often pulls new container images.
which can take a long time. Maybe a manual pre-pull of the images can help here... but it was not needed before.

I chose Podman for its simplicity over more complex solutions like k8s or k3s.
I suggest introducing a command like podman generate quadlet (which generates quadlet files and configs from an running podman project) to ease the transition and keep the simplicity that Podman offers.

[vrothberg]

As mentioned above, there is a project to generate Quadlets: https://github.com/k9withabone/podlet

I do not want to add that functionality to Podman as the ultimately goal is to move away from the workflow of generating systemd units based on existing containers. With Quadlet we aim at a Compose and K8s-like declarative workflow. Adding podman generate quadlet conflicts with that goal and it would imply that new Quadlet features had to be added there as well.

The current strategy is to deprecate podman generate systemd. That means that no new features will be added to generate systemd but only bug fixes.

[Pamalosebi]

the ultimately goal is to move away from the workflow of generating systemd units based on existing containers

ok... well, I don't have to understand everything. I just don't see the advantage for your users.

[vrothberg]

Maybe it doesn't fit your use case which is OK. Where I see the advantage is the reduced/improved workflow.

Previously, the worklflow roughly looked as follows:

1. Create a container on the CLI
2. Run podman generate systemd
3. Install the unit file(s)
4. Reload the daemon + Start

After an update to Podman, the entire process had to be repeated in case there were fixes to podman generate systemd.

With Quadlet, the workflow is reduced to installing the files and reloading the daemon and starting the service. Services may also start automatically on boot. After updates, nothing has to be changed or done by the user. The underlying units are transparently generated by Quadlet.

Update: That means the responsibility of fixing potential issues in the generated units is not on the user.

[Pamalosebi]

OK. For the absolute basic standard user, this seems better.
Unfortunately, it kills `podman-compose' and indeed long working setups.

[vrothberg]

Quadlet originates from the automotive teams which I do not consider to be standard users. It addresses real needs and long-standing workflow issues we've been hearing from users.

Unfortunately, it kills `podman-compose' and indeed long working setups.

Can you elaborate on that? I do not see how it would impact podman-compose since Quadlet focuses on running containers under systemd which isn't something Compose addresses.

[nivekuil]

+1 for the use case of converting "podman [pod] run" to systemd units. I was planning to just roll my own systemd generator since the rate of breakage in podman is quite high in general; going by the pattern quadlet will probably be deprecated in 2-3 years.

[rhatdan]

That seems a little harsh. We believe we built a better way to run podman containers under systemd, and want to deprecate a different way the Podman can do it.

[nivekuil]

not saying quadlet isn't better for podman, but podman itself seems to prioritize being an application more than a platform. Giving users good stuff faster isn't necessarily a bad thing, but there's inevitably some tension here with stability.

[rhatdan]

Well stability has not been broken, since we gave you a warning, if there is sufficient warning and push back, it could be reconsidered.

[nivekuil]

not broken, but in tension. That tension provoked this discussion: how should users building tools atop podman respond to this warning? That's the topic at hand, and my advice to @Pamalosebi is that long term it's better to reduce reliance on podman. That's true for any dependency of course, but I would feel a lot better about relying on systemd directly here than the new podman-specific way to do it.

[Pamalosebi]

I thought about it the last few days. When the whole wave of frustration calmed down.
I think my way in the future will be to write systemd service files manually.

Something like:

# <container-name>.service

[Unit]
Description=Podman service for running <container-name>
Documentation=https://docs.podman.io/en/latest/index.html
Wants=network-online.target
After=network-online.target
RequiresMountsFor=/run/user/<user-id>/containers

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
User=<username>
Group=<groupname>
Restart=on-failure
TimeoutStopSec=65
ExecStart=/usr/bin/podman start <container-name>
ExecStop=/usr/bin/podman stop -t 5 <container-name>
PIDFile=/run/user/<user-id>/containers/overlay-containers/<container-name>/userdata/conmon.pid
Type=forking

[Install]
WantedBy=default.target

Maybe I could take this a bit further... and take the "container-name" directly from the compose files. Also the user ID.
Then it would just be a tiny tweak to my previous script since the service files are generated automatically again.

That doesn't mean I'm happy about the change. It's just the way to keep working with podman.
Personally, I can't see the advantage of quadlets (for my usecase!)... So, I try to work around it.

[rugk]

I basically have the same question, I just also use https://github.com/containers/podman-compose. And I would love to deprecate that and move to Quadlet as that sounds very good for my use case. (I have just read about it.)

Actually, let's see my current process…

Current process

I write docker-compose.yml files as I think they are the most portable (and not as complicated as Kubernetes YAMLs and well I have not learned the latter and think it/a kubernetes cluster is "too much" for my use-case). Anyway, I use these and start it via https://github.com/containers/podman-compose. That works, except that podman-compose project seems understaffed, had (IMHO unexpected) big breaking changes (ref containers/podman-compose#504) and generally slow updates, so is is quite unstable. That is why I would have no problem with moving to an officially supported way like Quadlets. Especially as I think running these via systemd seems a slim enough (stack), as I have been afraid of Kubernetes for now.
Anyway, my process is not finished, because now here comes the question. I have, after having these containers up and running, of course used podman generate systemd to generate systemd units and then I did not have to run podman-compose anymore, except for when I wanted to change the setup.

So the process was like this, in short: docker-compose.yml -> podman-compose up -> podman generate systemd.
As such, as I end up with systemd unit files anyway, you may see why I would like to switch to Quadlets.

What I want

Now, what is the migration path here?
Is there an podman generate quadlet (have not seen it)? Or can I use podman generate kube and then generate a Quadlet out of the kube file(s)?

That would be awesome, because then I could switch to that and convert/keep my current configuration.

[Pamalosebi]

@rugk

And BTW my main reason for not using docker (compose) is I don't want a rootfull daemon, and podman is made for that while being compatible quite much.

Just saying... in case of emergency this is a thing: https://docs.docker.com/engine/security/rootless/

@vrothberg

I mentioned it already but I want to reiterate: there are no plans to remove podman-generate-systemd, so you can just continue using that. Migrating to Quadlet is recommended but it is not enforced.

Okay, its just so that everytime I execute "podman generate systemd" I get:

DEPRECATED command:
It is recommended to use Quadlets for running containers and pods under systemd.

Please refer to podman-systemd.unit(5) for details.

Nobody should continue to build on top of this feature.¯\_(ツ)_/¯

[vrothberg]

Nobody should continue to build on top of this feature.¯_(ツ)_/¯

Do you have an alternative idea how to notify/incentivize users to migrate to Quadlet? The warning is emitted on stderr to avoid breaking automation scripts that may parse stdout.

[Pamalosebi]

I used the weekend to implement / replace the "podman generate systemd" fully with Ansible.
Therefore I am not using the function anymore as it is natively implemented and I can keep working as it is.
Even if the project decides it is time to remove it.

Do you have an alternative idea how to notify/incentivize users to migrate to Quadlet?

No, it is good that it is very present. And then everyone can solve it the way they want to.

I mean... everything else about podman is working like a charm. Thank you for your work on Podman.

[vrothberg]

I used the weekend to implement / replace the "podman generate systemd" fully with Ansible.

Did you use the Ansible System Role for Podman? The latest version of it supports Quadlet as well.

[Pamalosebi]

Hmm... no. I just used containers.podman.podman_container_info to exract the podman container ID.
Which is used in the service files to manage the containers.

[DaveWK]

I read through all the previous discussion, but don't see a clear "call to action" here -- as an end user of podman, when I call podman generate systemd --new --files --name <my-pod-name>

and get back DEPRECATED command: blablabla

..which to me, as an end user: "hey! you're doing something the old way which we will be retiring soon." -- when I get something like that I would expect there also to be a pretty concise and coherent message about what exactly I am supposed to be doing "the new way", which I am not just not groking from the discussion..

What exactly should I do to be running a container in podman via systemd in 2024 "the right/new way"?

EDIT: I don't understand or really care what a quadlet is, but if I am supposed to use them to make podman run something in systemd, how I make one?

[rhatdan]

There are a few blogs on using quadlet
https://www.redhat.com/sysadmin/quadlet-podman
https://www.redhat.com/sysadmin/multi-container-application-podman-quadlet
Then there is the man page

man quadlet

[rugk]

man quadlet

Totally underrated and as I read this… wow 🤯 😲
I did not understand this exists (it's written nowhere) and it's also not easily findable if you search (via tab) for something like podman-quadlet or other podman-* things (which already yields 217 results/commands – so this does not even seem to be all).

[rhatdan]

$ man -k quadlet
podman-systemd.unit (5) - systemd units using Podman Quadlet
quadlet (5) - systemd units using Podman Quadlet

Hint they are both the same document.

[rugk]

Don't know if it is a bug, but in Fedora SIlverblue that command does not work:

$ man -k quadlet         
quadlet: nothing appropriate.

While man quadlet e.g. works and podman-systemd.unit, too.

[rhatdan]

I think this means Silverblue is not populating the man page cache. mandb?

[janpfeil]

I still got no answer from the long discussion: How do I generate the systemd .service files from my existing compose.yml files?
Is there any bash script provided?

[janpfeil]

Found it: podlet compose

[stuartm]

My wasted afternoon - A user story:

Like most here, I was left scratching my head by a mysterious "you're doing it wrong dummy" message displayed when running podman generate systemd. What are Quadlets?

So down the rabbit hole I go. A search engine sends me to the official documentation which happily tells me how much easier Quadlets will make my life. I try curb my cynicism because maybe this time that claim is made it will actually be true? What follows in the documentation immediately makes a lie of that claim, for I'm told that instead of running a simple one-liner to generate a service file I now need to hand craft an intermediate configuration file that will then be used to generate that same service file. A sure fire win for abstraction and obfuscation.

< OK. Deep breath. Must not lose temper, be civil and courteous ... >

An example of this.container file is given, it looks simple and straightforward. Then again the example use case is about as basic and well useless as it gets. In digging deeper, much, much deeper it turns out that for a real world use case, with a real world container requiring networking, loading of external variables, local volume mounts and more this container file actually becomes a complete re-write of the compose.yaml in a brand new and different format with different syntax. By hand.

< Sigh >

This can't be right, they said this was better, that it was easier. Let's do some more research, what was this thing called again ... podlet? Sure let's search for podlet ... Oh, OK, not what I meant to search for, but brilliant find. It turns out there IS a way to generate these files from those existing standard compose.yaml and even a running container. Hang on, though, why isn't this standard?? Why isn't this the behaviour of podman generate systemd? Ahh, it's a third party effort - well, way to go k9withabone! Let me just run this -

podlet compose compose.yaml
-bash: podlet: command not found

Doh. Not installed, stupid me.

dnf install podlet
No match for argument: podlet
Error: Unable to find a match: podlet

< Long exasperated sigh >

Looks at time. Wasted 2 hours already to do what used to take 10 seconds. At this point I'll save you the odyssey of getting podlet installed except to say that container install wouldn't work due to mysterious permission issues, both methods of cargo install failed halfway through on F39 and finally got there another hour later using the binary download. Generated my container file, finally. Would have been faster by hand after all, but hindsight and at least this should be faster for all those other containers.

Install my .container file to /etc/containers/systemd/ as the documentation tells me to do. Run systemctl daemon-reload. Almost there ... enable the service and ... Failed to enable unit: Unit file foo.service does not exist..

< Scream >

Back to the documentation. There's a second location given, that must be the answer. Moved the container file there, reload, still no .service file generated.

< THUD Sound of head hitting desk >

Run podman generate systemd foo > /etc/systemd/system/foo.service; systemctl enable foo; systemctl start foo.

Realisation - later versions of podman may drop simple systemd functionality and significantly complicate my life. Solution:

dnf versionlock podman

Finally gets back to doing real work before boss asks why I've spent a whole afternoon on something that should have taken seconds. The End.

[vrothberg]

Thanks a lot for your time sharing your experience, @stuartm!

I am sorry you feel like having wasted 2 hours. At the moment, there are no plans to remove generate systemd as we know and appreciate that it's being widely used. The upcoming Podman 5.0 does not remove it. So there is no need to version lock Podman. "Deprecation" in this context means that we will not be adding new features but only address critical bugs. So you can continue using generate systemd.

I will carefully re-read your comment on Monday and reply to your questions. This is useful feedback and I hope we can improve the documentation and user experience.

[jafd]

"Deprecation" in this context means that we will not be adding new features but only address critical bugs.

Could you then please call it "feature-complete" or "done", which is Good™, meaning "we promise we won't be moving your cheese", and not "deprecated", which is Bad™, meaning "we are going to disappear it any day now"?

[vrothberg]

What follows in the documentation immediately makes a lie of that claim, for I'm told that instead of running a simple one-liner to generate a service file I now need to hand craft an intermediate configuration file that will then be used to generate that same service file. A sure fire win for abstraction and obfuscation.

I don't think that using generate-systemd is a simple one-liner. The container needs to be created first, and then generate-systemd can generate service file based on that container. The service file must then be enabled/started.

Using Quadlet, a file must be written once is then automatically loaded. Quadlet is especially beneficial for day-2 operations. Let's assume there is a fix for the .service generator. With generate-systemd, the files must be recreated manually while it's fully transparent using Quadlet without any manual intervention.

In digging deeper, much, much deeper it turns out that for a real world use case, with a real world container requiring networking, loading of external variables, local volume mounts and more this container file actually becomes a complete re-write of the compose.yaml in a brand new and different format with different syntax. By hand.

That is a fair point. Migrating from Docker Compose to Quadlet requires work and there is no silver bullet.

This can't be right, they said this was better, that it was easier.

I do believe Quadlet is easier and better than generate-systemd once migrated. There is no trivial migration path though.

Let's do some more research, what was this thing called again ... podlet? [...] Hang on, though, why isn't this standard?? Why isn't this the behaviour of podman generate systemd?

podlet is a community project and not part of Podman. We want to discourage the old workflow of creating containers/pods first and then generating .service files. I understand that this requires manual work migrating off generate-systemd. That is why we do not want to remove generate-systemd and decided to keep it. No new features but urgent bug fixes.

Maybe we should add that to the deprecation notice when running generate-systemd?

Install my .container file to /etc/containers/systemd/ as the documentation tells me to do [...]

That depends whether you want to run the .service as root or not. /etc/containers/systemd is only accessible as root, /etc/containers/systemd/users/ and .../$(UID) is accessible for rootless users (plus the $HOME/.config dirs).

I believe we need to improve the docs to make the behavior clearer. That is very valuable feedback, thank you!

[amasolov]

Install my .container file to /etc/containers/systemd/ as the documentation tells me to do [...]

That depends whether you want to run the .service as root or not. /etc/containers/systemd is only accessible as root, /etc/containers/systemd/users/ and .../$(UID) is accessible for rootless users (plus the $HOME/.config dirs).

Adding a .container or a .service file to /etc/containers/systemd does't add anything to 'systemctl list-units' after doing 'systemctl daemon-reload'. I can relate to what was shared earlier by @jafd. It's a frustrating experience and a waste of time.

[ygalblum]

/etc/containers/systemd is a Quadlet input directory. So, adding .service files will not do anything.

As for the .container file, can you please verify the file with a dry run:
/usr/libexec/podman/quadlet -dryrun