Problems with podman generate systemd #5485
Assignees
Labels
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
Comments
openshift-ci-robot
added
the
kind/bug
|
@vrothberg PTAL |
|
could we add a |
That will only work for containers that have been named but won't work for unnamed containers. |
|
No issues here, sounds reasonable to do
…On Fri, Mar 13, 2020, 06:21 Valentin Rothberg ***@***.***> wrote:
could we add a ExecStartPre that does a rm -f?
That will only work for containers that have been named but won't work for
unnamed containers.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5485 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3AOCHKCAX5D5UN6NJ4QZLRHICJHANCNFSM4LGVPUBA>
.
|
|
A friendly reminder that this issue had no activity for 30 days. |
|
@larsks @vrothberg Does this issue still exist? |
|
Yes. The idea is to add |
|
@vrothberg Any progress on this? |
|
Thanks for the ping. No progress yet but I'll tackle it now. |
vrothberg
added a commit
to vrothberg/libpod
that referenced
this issue
Jun 15, 2020
Add a `--replace` flag to the `container {create,run}` commands.
If another container with the same name already exists, it will
be replaced and removed.
Adding this flag is motivated by containers#5485 to make running Podman in systemd
units (or any other scripts/automation) more robust. In case of a
crash, a container may not be removed by a sytemd unit anymore. The
`--replace` flag allows for supporting crashes.
Signed-off-by: Valentin Rothberg <[email protected]>
vrothberg
added a commit
to vrothberg/libpod
that referenced
this issue
Jun 15, 2020
Add a `--replace` flag to the `pod create` command. If another pod with the same name already exists, it will be replaced and removed. Adding this flag is motivated by containers#5485 to make running Podman in systemd units (or any other scripts/automation) more robust. In case of a crash, a pod may not be removed by a sytemd unit anymore. The `--replace` flag allows for supporting crashes. Note that the `--replace` flag does not require the `--name` flag to be set, so it can be set unconditionally in `podman generate systemd`. Signed-off-by: Valentin Rothberg <[email protected]>
vrothberg
added a commit
to vrothberg/libpod
that referenced
this issue
Jun 15, 2020
Use `--replace` for named containers and pods. This will clean up previous containers and podsthat may not have been removed after a system crash. Fixes: containers#5485 Signed-off-by: Valentin Rothberg <[email protected]>
|
#6553 will fix it 👍 |
github-actions
bot
added
the
locked - please file new issue/PR
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
The unit files produced by
podman generate systemd --new ...are problematic because they will fail to start the service if the system crashes. This happens because the container is only removed as part ofExecStopPost, and during a crash (/power failure/etc) that never runs. The result is that a subsequent attempt to start the service will fail withError: error creating container storage: the container name "your_container_name" is already in use by ....You can't simply drop the
--new, because then the resulting unit file won't actually create the container if it doesn't exist.What you really need to make this robust is one of two things:
Tie the lifetime of the container to the lifetime of the
podmancommand. When thepodmanexits, the container is gone. This would make a containerized service behave like a normal un-containerized service, which would work well with a process manager likesystemd.Allow replacing an existing container with a new container. E.g., introduce a
--replaceflag topodman runso thatpodman run --replace --name foo ...would permit create a new container namedfooeven if one already exists.The text was updated successfully, but these errors were encountered: