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
podman restart behaves not the same as podman stop && podman start (firewalld specific?) #5051
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
Categorizes issue or PR as related to a bug.
label
Feb 2, 2020
Hm. I think we might be reusing the old network namespace - which, as you point out here, could be a bad thing in certain circumstances. |
Confirmed, we're not tearing down the network namespace when we stop the container. Easy fix, I think. |
mheon
added a commit
to mheon/libpod
that referenced
this issue
Feb 2, 2020
This makes restart a bit slower for root containers, but it does make it more consistent with `podman stop` and `podman start` on a container. Importantly, `podman restart` will now recreate firewall rules if they were somehow purged. Fixes containers#5051 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Fix in #5052 |
Now that's what I call a quick fix! I'll assume that it's going to be merged and close this one... Cheers |
sujil02
pushed a commit
to sujil02/podman
that referenced
this issue
Feb 7, 2020
This makes restart a bit slower for root containers, but it does make it more consistent with `podman stop` and `podman start` on a container. Importantly, `podman restart` will now recreate firewall rules if they were somehow purged. Fixes containers#5051 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
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 23, 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.
/kind bug
Description
The command
podman restart mycontainer
appears to behave differently from
podman stop mycontainer && podman start mycontainer
This is observed when a container which needs internet access via the host is restarted, which apparently does not update the firewall rules (in my case on Fedora adding e.g.
10.88.0.31/32
to the trusted zone, where the ip is the one of the container).After the restart, the container networking is broken.
If, instead,
podman stop
is used, the firewall rule is removed, and a new one put in place (matching the new container ip) afterpodman start
I am running firewalld with nftables backend, which is also specified in
/etc/cni/net.d/87-podman-bridge.conflist
as{ "type": "firewall", "backend": "nftables" },
Steps to reproduce the issue:
execute
podman restart mycontainer
vs
podman stop mycontainer && podman start mycontainer
Describe the results you received:
Firewall rules are unaffected and networking (e.g. network request from the container on a host running firewalld) is broken for the first command.
Describe the results you expected:
Firewall rules are updated the same as when using
podman stop
(deletes container specific ip in trusted zone) andpodman start
(creates corresponding new rule)Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):The text was updated successfully, but these errors were encountered: