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

CNI-in-slirp4netns mode hangs (podman-3.2.2-1.fc34.x86_64; very recent regression) #10928

Closed
AkihiroSuda opened this issue Jul 14, 2021 · 4 comments
Labels
CNI Bug with CNI networking for root containers 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. rootless

Comments

@AkihiroSuda
Copy link
Collaborator

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

CNI-in-slirp4netns mode hangs (podman-3.2.2-1.fc34.x86_64).

Very recent regression, originally reported by @xinydev in kubernetes-sigs/kind#2361

Steps to reproduce the issue:

[vagrant@fedora ~]$ podman network create foo
/home/vagrant/.config/cni/net.d/foo.conflist
[vagrant@fedora ~]$ podman run -it --rm --network foo docker.io/library/hello-world
Trying to pull docker.io/library/hello-world:latest...
Getting image source signatures
Copying blob b8dfde127a29 done  
Copying config d1165f2212 done  
Writing manifest to image destination
Storing signatures
(Hangs up here)

Describe the results you received:

Hangs up

Describe the results you expected:

Should not hang

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

Very recent regression.

Output of podman version:

[vagrant@fedora ~]$ podman version
Version:      3.2.2
API Version:  3.2.2
Go Version:   go1.16.4
Built:        Fri Jun 25 23:49:19 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

[vagrant@fedora ~]$ podman info --debug
host:
  arch: amd64
  buildahVersion: 1.21.0
  cgroupControllers: []
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.27-2.fc34.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.27, commit: '
  cpus: 2
  distribution:
    distribution: fedora
    version: "34"
  eventLogger: journald
  hostname: fedora
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.11.12-300.fc34.x86_64
  linkmode: dynamic
  memFree: 3261812736
  memTotal: 4116054016
  ociRuntime:
    name: crun
    package: crun-0.20.1-1.fc34.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.20.1
      commit: 0d42f1109fd73548f44b01b3e84d04a279e99d2e
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.9-1.fc34.x86_64
    version: |-
      slirp4netns version 1.1.8+dev
      commit: 6dc0186e020232ae1a6fcc1f7afbc3ea02fd3876
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 0
  swapTotal: 0
  uptime: 8m 0.44s
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/vagrant/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.5.0-1.fc34.x86_64
      Version: |-
        fusermount3 version: 3.10.2
        fuse-overlayfs: version 1.5
        FUSE library version 3.10.2
        using FUSE kernel interface version 7.31
  graphRoot: /home/vagrant/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /run/user/1000/containers
  volumePath: /home/vagrant/.local/share/containers/storage/volumes
version:
  APIVersion: 3.2.2
  Built: 1624664959
  BuiltTime: Fri Jun 25 23:49:19 2021
  GitCommit: ""
  GoVersion: go1.16.4
  OsArch: linux/amd64
  Version: 3.2.2

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

[vagrant@fedora ~]$ rpm -q podman
podman-3.2.2-1.fc34.x86_64

**Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)**

Yes.


**Additional environment details (AWS, VirtualBox, physical, etc.):**

Vagrantfile:
```ruby
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "fedora/34-cloud-base"
  config.vm.provider :virtualbox do |v|
    v.memory = 4096
    v.cpus = 2
  end
  config.vm.provision "shell", inline: <<-SHELL
  set -eux -o pipefail
  dnf install -y podman
  SHELL
end
@AkihiroSuda AkihiroSuda added rootless kind/bug Categorizes issue or PR as related to a bug. CNI Bug with CNI networking for root containers labels Jul 14, 2021
@AkihiroSuda
Copy link
Collaborator Author

The issue is reproducible on the Fedora 34 Vagrantfile above, but can't repro on Ubuntu 21.10 with git checkout v3.2.2 && make && sudo make install.

@AkihiroSuda
Copy link
Collaborator Author

AkihiroSuda commented Jul 14, 2021

A workaround seems to be run some rootful container before running a rootless container. Probably related to modprobe stuff.

Running dnf upgrade and then rebooting seems also work.

@Luap99
Copy link
Member

Luap99 commented Jul 14, 2021

Should be already fixed in main #10865.
You have to create the /var/lib/cni directory on the host as workaround.

@AkihiroSuda
Copy link
Collaborator Author

Thanks

@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 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CNI Bug with CNI networking for root containers 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. rootless
Projects
None yet
Development

No branches or pull requests

2 participants