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 inspect returns invalid values for unlimited ulimits #9303

Closed
mpolden opened this issue Feb 10, 2021 · 0 comments · Fixed by #9309
Closed

Podman inspect returns invalid values for unlimited ulimits #9303

mpolden opened this issue Feb 10, 2021 · 0 comments · Fixed by #9309
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

@mpolden
Copy link

mpolden commented Feb 10, 2021

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

/kind bug

Description

Steps to reproduce the issue:

  1. Run a container with unlimited core size:

    podman run --rm --name test --ulimit core=-1:-1 -it debian:latest /bin/bash
    
  2. Inspect the container ulimits:

    podman inspect test | grep -B 1 -A 3 -F RLIMIT_CORE
    

Describe the results you received:

Inspect returns the following:

                {
                    "Name": "RLIMIT_CORE",
                    "Soft": 18446744073709551615,
                    "Hard": 18446744073709551615
                },

Describe the results you expected:

                {
                    "Name": "RLIMIT_CORE",
                    "Soft": -1,
                    "Hard": -1
                },

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

The returned value is 2^64-1, so this probably happens because Podman uses unsigned integers for these values and overflows.

Output of podman version:

Version:      2.0.5
API Version:  1
Go Version:   go1.14.7
Built:        Wed Sep 23 16:18:02 2020
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.15.1
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.20-2.module+el8.3.0+8221+97165c3f.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.20, commit: 77ce9fd1e61ea89bd6cdc621b07446dd9e80e5b6'
  cpus: 24
  distribution:
    distribution: '"rhel"'
    version: "8.3"
  eventLogger: file
  hostname: <snip>
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 100
      size: 1
    uidmap:
    - container_id: 0
      host_id: 87591
      size: 1
  kernel: 4.18.0-240.10.1.el8_3.x86_64
  linkmode: dynamic
  memFree: 16772780032
  memTotal: 25032122368
  ociRuntime:
    name: runc
    package: runc-1.0.0-68.rc92.module+el8.3.0+8221+97165c3f.x86_64
    path: /usr/bin/runc
    version: 'runc version spec: 1.0.2-dev'
  os: linux
  remoteSocket:
    path: /run/user/87591/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.4-2.module+el8.3.0+8221+97165c3f.x86_64
    version: |-
      slirp4netns version 1.1.4
      commit: b66ffa8e262507e37fca689822d23430f3357fe8
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
  swapFree: 0
  swapTotal: 0
  uptime: 123h 47m 49.47s (Approximately 5.12 days)
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /home/mpolden/.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.1.2-3.module+el8.3.0+8221+97165c3f.x86_64
      Version: |-
        fuse-overlayfs: version 1.1.0
        FUSE library version 3.2.1
        using FUSE kernel interface version 7.26
  graphRoot: /home/mpolden/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 0
  runRoot: /run/user/87591/containers
  volumePath: /home/mpolden/.local/share/containers/storage/volumes
version:
  APIVersion: 1
  Built: 1600877882
  BuiltTime: Wed Sep 23 16:18:02 2020
  GitCommit: ""
  GoVersion: go1.14.7
  OsArch: linux/amd64
  Version: 2.0.5

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

podman-2.0.5-5.module+el8.3.0+8221+97165c3f.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

No.

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

Physical machine running Red Hat Enterprise Linux release 8.3 (Ootpa).

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Feb 10, 2021
baude added a commit to baude/podman that referenced this issue Feb 10, 2021
When doing a container inspect on a container with unlimited ulimits,
the value should be -1.  But because the OCI spec requires the ulimit
value to be uint64, we were displaying the inspect values as a uint64 as
well.  Simple change to display as an int64.

Fixes: containers#9303

Signed-off-by: baude <bbaude@redhat.com>
baude added a commit to baude/podman that referenced this issue Feb 10, 2021
When doing a container inspect on a container with unlimited ulimits,
the value should be -1.  But because the OCI spec requires the ulimit
value to be uint64, we were displaying the inspect values as a uint64 as
well.  Simple change to display as an int64.

Fixes: containers#9303

Signed-off-by: baude <bbaude@redhat.com>
mheon pushed a commit to mheon/libpod that referenced this issue Feb 11, 2021
When doing a container inspect on a container with unlimited ulimits,
the value should be -1.  But because the OCI spec requires the ulimit
value to be uint64, we were displaying the inspect values as a uint64 as
well.  Simple change to display as an int64.

Fixes: containers#9303

Signed-off-by: baude <bbaude@redhat.com>
@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 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 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.

2 participants