New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Containers stop if dependency gets updated #18926
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
Thanks for reaching out, @M1cha! I can reproduce. Internally |
vrothberg
added a commit
to vrothberg/libpod
that referenced
this issue
Jun 19, 2023
Commit f131eaa changed restart to a stop+start motivated by comments in the systemd man pages that restart behaves different than stop+start, for instance, that it keeps certain resources open and treats timers differently. Yet, the actually fix for containers#17607 in the very same commit was dealing with an ENOENT of the CID file on container removal. As it turns out in in containers#18926, changing to stop+start regressed on restarting dependencies when auto updating a systemd unit. Hence, move back to using restart to make sure that dependent systemd units are restarted as well. An alternative could be recommending to use `BindsTo=` in Quadlet files but this seems less common than `Requires=` and hence more risky to cause issues on user sites. Fixes: containers#18926 Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
cgiradkar
pushed a commit
to cgiradkar/podman
that referenced
this issue
Jul 12, 2023
Commit f131eaa changed restart to a stop+start motivated by comments in the systemd man pages that restart behaves different than stop+start, for instance, that it keeps certain resources open and treats timers differently. Yet, the actually fix for containers#17607 in the very same commit was dealing with an ENOENT of the CID file on container removal. As it turns out in in containers#18926, changing to stop+start regressed on restarting dependencies when auto updating a systemd unit. Hence, move back to using restart to make sure that dependent systemd units are restarted as well. An alternative could be recommending to use `BindsTo=` in Quadlet files but this seems less common than `Requires=` and hence more risky to cause issues on user sites. Fixes: containers#18926 Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
cgiradkar
pushed a commit
to cgiradkar/podman
that referenced
this issue
Jul 13, 2023
Commit f131eaa changed restart to a stop+start motivated by comments in the systemd man pages that restart behaves different than stop+start, for instance, that it keeps certain resources open and treats timers differently. Yet, the actually fix for containers#17607 in the very same commit was dealing with an ENOENT of the CID file on container removal. As it turns out in in containers#18926, changing to stop+start regressed on restarting dependencies when auto updating a systemd unit. Hence, move back to using restart to make sure that dependent systemd units are restarted as well. An alternative could be recommending to use `BindsTo=` in Quadlet files but this seems less common than `Requires=` and hence more risky to cause issues on user sites. Fixes: containers#18926 Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
cgiradkar
pushed a commit
to cgiradkar/podman
that referenced
this issue
Jul 17, 2023
Commit f131eaa changed restart to a stop+start motivated by comments in the systemd man pages that restart behaves different than stop+start, for instance, that it keeps certain resources open and treats timers differently. Yet, the actually fix for containers#17607 in the very same commit was dealing with an ENOENT of the CID file on container removal. As it turns out in in containers#18926, changing to stop+start regressed on restarting dependencies when auto updating a systemd unit. Hence, move back to using restart to make sure that dependent systemd units are restarted as well. An alternative could be recommending to use `BindsTo=` in Quadlet files but this seems less common than `Requires=` and hence more risky to cause issues on user sites. Fixes: containers#18926 Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
cgiradkar
pushed a commit
to cgiradkar/podman
that referenced
this issue
Jul 17, 2023
Commit f131eaa changed restart to a stop+start motivated by comments in the systemd man pages that restart behaves different than stop+start, for instance, that it keeps certain resources open and treats timers differently. Yet, the actually fix for containers#17607 in the very same commit was dealing with an ENOENT of the CID file on container removal. As it turns out in in containers#18926, changing to stop+start regressed on restarting dependencies when auto updating a systemd unit. Hence, move back to using restart to make sure that dependent systemd units are restarted as well. An alternative could be recommending to use `BindsTo=` in Quadlet files but this seems less common than `Requires=` and hence more risky to cause issues on user sites. Fixes: containers#18926 Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
github-actions
bot
added
the
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
label
Sep 18, 2023
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Issue Description
I have two podman-systemd containers:
They both have:
default.target
Restart=always
Label=io.containers.autoupdate=registry
photoprism depends on photoprism-mariadb due to:
Now, whenever photoprism-mariadb.service gets restarted because it was updated by
podman-auto-update.service
,photoprism
stops until I start it manually. If I runsystemctl restart photoprism-mariadb
,photoprism
will stop as well, but restart after 10 seconds as expected.Steps to reproduce the issue
Steps to reproduce the issue
Describe the results you received
The container stopped forever.
Describe the results you expected
The container should restart as expected.
podman info output
Podman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
Yes
Additional environment details
# cat /etc/containers/containers.conf
Additional information
No response
The text was updated successfully, but these errors were encountered: