Open ChristophHannappel opened 1 day ago
@ygalblum @alexlarsson @vrothberg Why are we setting RemainAfterExit in quadlet at all?
Quadlet sets RemainAfterExit
for all single shot services. I think the reason was that the original ones (.volume
and .network
) were actually one-offs that created the podman object and noop afterwards. So, there was no point in running them again (yes, they still run again after reboot).
I agree that Quadlet should check if the key is set in the Quadlet file and not override it.
What should the default for build be though, shouldn't it attempt a rebuild on each restart? (Also agree on not modifying if user sets the field.)
Is there a way to check if the user set this?
Is there a way to check if the user set this?
Yes. We do something similar for KillMode
here: https://github.com/containers/podman/blob/1ca42f0a16aeef1f303a654db2543f264a4bac55/pkg/systemd/quadlet/quadlet.go#L574
What should the default for build be though, shouldn't it attempt a rebuild on each restart?
Not sure
Issue Description
I've created a
.build
quadlet file which runs perfectly at the user context. Since the service is supposed to be started by a systemd.timer I've setRemainAfterExit=no
, but thepodman-system-generator
generates a systemd.service file where the OptionRemainAfterExit
ist set toyes
. Therefore the service never stops and can not be started again by a systemd.timerSteps to reproduce the issue
Steps to reproduce the issue
hetznerDNSUpdate.build
file:[Service] RemainAfterExit=no
[Build] ImageTag=localhost/hetznerdnsupdate:latest SetWorkingDirectory=/home/channappel/hetznerDocker Pull=newer
Describe the results you expected
At the
[Service]
Section the Option is set toRemainAfterExit=no
as specified in thehetznerDNSUpdate.build
File.podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
No
Additional environment details
Baremetal Fedora Server 40
Additional information
None