Skip to content
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

Closed
ppenguin opened this issue Feb 2, 2020 · 4 comments · Fixed by #5052
Closed
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

@ppenguin
Copy link

ppenguin commented Feb 2, 2020

/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) after podman 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) and podman start (creates corresponding new rule)

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

podman version 1.7.0

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.13.5
  podman version: 1.7.0
host:
  BuildahVersion: 1.12.0
  CgroupVersion: v2
  Conmon:
    package: conmon-2.0.9-2.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.9, commit: 7d46f3e7711aa3578488284ae2f98b447658f086'
  Distribution:
    distribution: fedora
    version: "31"
  MemFree: 281800704
  MemTotal: 16604254208
  OCIRuntime:
    name: crun
    package: crun-0.10.6-1.fc31.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.10.6
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  SwapFree: 7874539520
  SwapTotal: 7999582208
  arch: amd64
  cpus: 8
  eventlogger: journald
  hostname: microserv.fritz.box
  kernel: 5.4.12-200.fc31.x86_64
  os: linux
  rootless: false
  uptime: 168h 24m 22.16s (Approximately 7.00 days)
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
store:
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 4
  GraphDriverName: overlay
  GraphOptions:
    overlay.mountopt: nodev,metacopy=on
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  ImageStore:
    number: 7
  RunRoot: /var/run/containers/storage
  VolumePath: /var/lib/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):

podman-1.7.0-2.fc31.x86_64
@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Feb 2, 2020
@mheon
Copy link
Member

mheon commented 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.

@mheon
Copy link
Member

mheon commented Feb 2, 2020

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>
@mheon
Copy link
Member

mheon commented Feb 2, 2020

Fix in #5052

@ppenguin
Copy link
Author

ppenguin commented Feb 2, 2020

Now that's what I call a quick fix!
Thanks!

I'll assume that it's going to be merged and close this one... Cheers

@ppenguin ppenguin closed this as completed Feb 2, 2020
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 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
@github-actions github-actions bot locked as resolved and limited conversation to collaborators 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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants