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

make the cpuset cgroup optional #1134

Closed
martinetd opened this issue Aug 26, 2022 · 2 comments · Fixed by #1135
Closed

make the cpuset cgroup optional #1134

martinetd opened this issue Aug 26, 2022 · 2 comments · Fixed by #1135

Comments

@martinetd
Copy link
Contributor

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

/kind feature

Description

podman works, but prints a warning on one of our new boards where we don't have the cpuset cgroup enabled (CONFIG_CPUSET requires CONFIG_SMP and the system we target only has a single core, so we'd rather not build with SMP enabled), and in turn disables cgroup isolation for this system.

Here's the warning:

Failed to add conmon to cgroupfs sandbox cgroup: open /sys/fs/cgroup/libpod_parent/conmon/cpuset.cpus: open /sys/fs/cgroup/libpod_parent/conmon/cpuset.cpus.effective: no such file or directory

There's two things:

  • the warning is noisy and will make our users ask us what it is about all the time, so we'd eventually need a way to silence it -- for now it's easy enough to pass --cgroups=disabled but if next point is fixed we'll probably want a toggle to keep it quiet?
  • cgroup ends up disabled despite having everything else it needs, it'd be great if it could work with the cgroups it found instead.
    I understand podman doesn't deal with no-SMP systems often, but these still exist and new ones are still made so it'd be great if we could find a way to work around this.

I'm not sure what implications there would be to enable cgroups without the cpuset parts; pkg/cgroups/cpuset.go only copies the cgroup from parent's so it doesn't seem like it'd be such a big deal to skip this one but others have Stat/Apply functions and might be used in places that wouldn't expect the cgroup to be missing... My gut feeling is cpuset is just not used much and could work out the simple "just make this one optional" way -- what do you think?

Steps to reproduce the issue:

  1. build/find a system without cpuset nor systemd

  2. run a podman container

Describe the results you received:

warning displayed

Describe the results you expected:

handle this more gracefully?

Output of podman version:

# podman version
Client:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.18.5
Git Commit:   428aafd4c2e1b926bb38edfd883257074b981d7c
Built:        Fri Aug  5 12:41:43 2022
OS/Arch:      linux/arm64

Output of podman info:

host:
  arch: arm
  buildahVersion: 1.26.1
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  - rdma
  cgroupManager: cgroupfs
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.2-r0
    path: /usr/bin/conmon
    version: 'conmon version 2.1.2, commit: f25214cda836296fe8695c2e582ca79d2246053a'
  cpuUtilization:
    idlePercent: 0.19
    systemPercent: 28.22
    userPercent: 71.58
  cpus: 1
  distribution:
    distribution: alpine
    version: 3.16.2
  eventLogger: file
  hostname: armadillo
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.10.126-19-at
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 411127808
  memTotal: 509145088
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.4.5-r0
    path: /usr/bin/crun
    version: |-
      crun version 1.4.5
      commit: c381048530aa750495cf502ddb7181f2ded5b400
      spec: 1.0.0
      +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/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: false
    seccompEnabled: true
    seccompProfilePath: /etc/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-r0
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.2
  swapFree: 0
  swapTotal: 0
  uptime: 58.85s
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.imagestore: /var/lib/containers/storage_readonly
    overlay.mountopt: nodev
  graphRoot: /run/containers/storage_root
  graphRootAllocated: 101830656
  graphRootUsed: 745472
  graphStatus:
    Backing Filesystem: tmpfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /run/containers/storage
  volumePath: /run/containers/storage_root/volumes
version:
  APIVersion: 4.1.1
  Built: 1659670903
  BuiltTime: Fri Aug  5 12:41:43 2022
  GitCommit: 428aafd4c2e1b926bb38edfd883257074b981d7c-dirty
  GoVersion: go1.18.5
  Os: linux
  OsArch: linux/arm
  Version: 4.1.1
@giuseppe
Copy link
Member

I think we shouldn't error out if the cpuset controller is not available and we are just copying the default configuration

@giuseppe giuseppe transferred this issue from containers/podman Aug 26, 2022
giuseppe added a commit to giuseppe/common that referenced this issue Aug 26, 2022
if cpuset.cpus[.effective] file is missing, then ignore the error
since it means the cpuset controller is not enabled in the kernel,
rather than returning an error.

Closes: containers#1134

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
@giuseppe
Copy link
Member

opened a PR: #1135

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants