quadlets fully depend on systemd doing its work. So, assuming you are running rootless, if you change your quadlets, you will need

  systemctl --user daemon-reload

to let systemd ingest the changes. And, if you have configured to start your container on boot, then still you have to start the container by hand, as you typically won't reboot during development. If you have multiple containers, it might be easiest to have them in one pod, so you only need to start the pod.

I agree that the documentation needs a good tutorial to show the complete concept as a starting point. There are multiple ones though on the internet.

▲ szszrk 3 hours ago | parent [-]

yeah, that's exactly what every tutorial says. And I know systemd more or less, daemon-reload is no stranger to me.

That was not sufficient. Both for global o user setup.

	▲	stryan an hour ago \| parent [-]
		The biggest problem with the `systemctl daemon-reload (--user)` workflow to register quadlets with systemd is it hides any generation errors in journald instead of giving immediate feedback. It's a real pain in the ass, and I say this from a place of love. Quadlets are just a systemd generator: all `daemon-reload` is doing is running `podman-system-generator` which looks at the Quadlet files and turns them into systemd unit files with a big honking `podman run --rm --blah container:tag` as the `ExecStart` property. There's nothing else to it, no daemons or what not If you ever feel like bothering to give it another shot check journalctl to see if there's any generator errors. Or run the generator directly: on my OpenSUSE box it's at `/usr/lib/systemd/system-generators/podman-system-generator` , Run it with `--dry-run` to just output to stdout and `--user` to get user quadlets.