podman: Error: setrlimit `RLIMIT_NOFILE`: Invalid argument: OCI runtime error

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

/kind bug

Description

unable to create containers

Steps to reproduce the issue:

  1. podman run -it --rm --name test alpine:latest

Describe the results you received: Error: setrlimit RLIMIT_NOFILE: Invalid argument: OCI runtime error

Describe the results you expected: The container to start

Additional information you deem important (e.g. issue happens only occasionally): podman run --ulimit host -it --rm --name test alpine:latest Using –ulimit host solves the issue.

Output of podman version:

Version:      2.0.1
API Version:  1
Go Version:   go1.14.3
Built:        Thu Jan  1 10:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.15.0
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.18-1.fc32.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.18, commit: 6e8799f576f11f902cd8a8d8b45b2b2caf636a85'
  cpus: 128
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: file
  hostname: hostname.com
  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.7.6-201.fc32.x86_64
  linkmode: dynamic
  memFree: 268024225792
  memTotal: 270138871808
  ociRuntime:
    name: crun
    package: crun-0.14-2.fc32.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.14
      commit: ebc56fc9bcce4b3208bb0079636c80545122bf58
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.1-1.fc32.x86_64
    version: |-
      slirp4netns version 1.1.1
      commit: bbf27c5acd4356edb97fa639b4e15e0cd56a39d5
      libslirp: 4.2.0
      SLIRP_CONFIG_VERSION_MAX: 2
  swapFree: 34359734272
  swapTotal: 34359734272
  uptime: 27m 59.31s
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 8
    paused: 0
    running: 0
    stopped: 8
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.1.1-1.fc32.x86_64
      Version: |-
        fusermount3 version: 3.9.1
        fuse-overlayfs: version 1.1.0
        FUSE library version 3.9.1
        using FUSE kernel interface version 7.31
  graphRoot: /home/user/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 9
  runRoot: /run/user/1000/containers
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 1
  Built: 0
  BuiltTime: Thu Jan  1 10:00:00 1970
  GitCommit: ""
  GoVersion: go1.14.3
  OsArch: linux/amd64
  Version: 2.0.1

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

podman-2.0.1-1.fc32.x86_64

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

ulimit -u --soft 8388608

ulimit -u --hard 8388608

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 18 (14 by maintainers)

Most upvoted comments

This has always been broken - I went back to v1.9.3 and that command is equally nonfunctional. This does not seem like a Podman issue. We briefly made containers with bad rlimits, and those containers were and still are unusable. New containers will work properly.

Is this Silverblue?

This issue is still happening in Podman v2.0.2, although it was supposed to be fixed there.

For more information see: https://github.com/containers/toolbox/issues/500#issuecomment-658424664