clair with podman on rhel 9.3 gets error of missing /sys/fs/cgroup/cpu.max

[flomickl]

H

I am running clair with podman on a rhel 9.3 with SELinux enabled.

If I start my container I get the following error in my logs:

{"level":"error","component":"main","error":"open /sys/fs/cgroup/cpu.max: no such file or directory","time":"2024-07-12T10:30:37Z","message":"unable to guess GOMAXPROCS value"}

I start clair with following podman run command and can't find anything, probably is wrong.

podman run \
  --name clair \
  --network quay-backend \
  --network clair-backend \
  --network traefik-proxy \
  -it \
  -d \
  -v /data/quay/config/clair/config.yaml:/src/clair/config.yaml:ro,Z \
  --env-file /data/quay/clair.env \
  -e TZ=Europe/Berlin \
  -e CLAIR_CONF="/src/clair/config.yaml" \
  -e CLAIR_MODE="combo" \
  -e CLAIR_DB_USER="clair" \
  -e CLAIR_DB_PASSWORD="clair" \
  -e TZ=Europe/Berlin \
  --label diun.enable=true \
  --label io.containers.autoupdate=registry \
  --health-cmd="curl -f http://localhost:8000/healthz || exit 1" \
  --health-interval=30s \
  --health-timeout=10s \
  --health-retries=3 \
  quay.io/projectquay/clair:4.7.4 \
  bash -c "cd /src/clair/cmd/clair; go run -mod vendor ."

Any Idea why and what this error message means?

Here are some more informations from my system. For me, it looks like that everything is set up by default and no idea why cpu.max seems to be missing.

uname -a

Linux redhat 5.14.0-427.24.1.el9_4.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jun 23 11:48:35 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux

podman version

Client:       Podman Engine
Version:      4.9.4-rhel
API Version:  4.9.4-rhel
Go Version:   go1.21.11 (Red Hat 1.21.11-1.el9_4)
Built:        Fri Jun 21 13:36:53 2024
OS/Arch:      linux/amd64

podman system info
host:
  arch: amd64
  buildahVersion: 1.33.7
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.10-1.el9.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.10, commit: fb8c4bf50dbc044a338137871b096eea8041a1fa'
  cpuUtilization:
    idlePercent: 87.53
    systemPercent: 7.44
    userPercent: 5.03
  cpus: 4
  databaseBackend: sqlite
  distribution:
    distribution: rhel
    version: "9.4"
  eventLogger: journald
  freeLocks: 1976
  hostname: redhat
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 2000
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 2000
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
  kernel: 5.14.0-427.24.1.el9_4.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 7898517504
  memTotal: 33271250944
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.10.0-3.el9_4.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.10.0
    package: netavark-1.10.3-1.el9.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.10.3
  ociRuntime:
    name: crun
    package: crun-1.14.3-1.el9.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.14.3
      commit: 1961d211ba98f532ea52d2e80f4c20359f241a98
      rundir: /run/user/2000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  pasta:
    executable: ""
    package: ""
    version: ""
  remoteSocket:
    exists: true
    path: /run/user/2000/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.2.3-1.el9.x86_64
    version: |-
      slirp4netns version 1.2.3
      commit: c22fde291bb35b354e6ca44d13be181c76a0a432
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.2
  swapFree: 16831737856
  swapTotal: 16831737856
  uptime: 5h 58m 16.00s (Approximately 0.21 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
   .....
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /home/pody/.config/containers/storage.conf
  containerStore:
    number: 7
    paused: 0
    running: 6
    stopped: 1
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/pody/.local/share/containers/storage
  graphRootAllocated: 930685026304
  graphRootUsed: 15197487104
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 6
  runRoot: /run/user/2000/containers
  transientStore: false
  volumePath: /home/pody/.local/share/containers/storage/volumes
version:
  APIVersion: 4.9.4-rhel
  Built: 1718969813
  BuiltTime: Fri Jun 21 13:36:53 2024
  GitCommit: ""
  GoVersion: go1.21.11 (Red Hat 1.21.11-1.el9_4)
  Os: linux
  OsArch: linux/amd64
  Version: 4.9.4-rhel

The Cgroup-Hierarchie ooks good to me as well

ls -l /sys/fs/cgroup
insgesamt 0
-r--r--r--.  1 root root 0 12. Jul 06:36 cgroup.controllers
-rw-r--r--.  1 root root 0 12. Jul 12:36 cgroup.max.depth
-rw-r--r--.  1 root root 0 12. Jul 12:36 cgroup.max.descendants
-rw-r--r--.  1 root root 0 12. Jul 06:36 cgroup.procs
-r--r--r--.  1 root root 0 12. Jul 12:36 cgroup.stat
-rw-r--r--.  1 root root 0 12. Jul 06:36 cgroup.subtree_control
-rw-r--r--.  1 root root 0 12. Jul 12:36 cgroup.threads
-r--r--r--.  1 root root 0 12. Jul 12:36 cpuset.cpus.effective
-r--r--r--.  1 root root 0 12. Jul 12:36 cpuset.cpus.isolated
-r--r--r--.  1 root root 0 12. Jul 12:36 cpuset.mems.effective
-r--r--r--.  1 root root 0 12. Jul 12:36 cpu.stat
drwxr-xr-x.  2 root root 0 12. Jul 06:36 dev-hugepages.mount
drwxr-xr-x.  2 root root 0 12. Jul 06:36 dev-mqueue.mount
drwxr-xr-x.  2 root root 0 12. Jul 06:36 init.scope
-r--r--r--.  1 root root 0 12. Jul 12:36 io.stat
-r--r--r--.  1 root root 0 12. Jul 12:36 memory.numa_stat
--w-------.  1 root root 0 12. Jul 12:36 memory.reclaim
-r--r--r--.  1 root root 0 12. Jul 12:36 memory.stat
-r--r--r--.  1 root root 0 12. Jul 12:36 misc.capacity
-r--r--r--.  1 root root 0 12. Jul 12:36 misc.current
drwxr-xr-x.  2 root root 0 12. Jul 06:36 sys-fs-fuse-connections.mount
drwxr-xr-x.  2 root root 0 12. Jul 06:36 sys-kernel-config.mount
drwxr-xr-x.  2 root root 0 12. Jul 06:36 sys-kernel-debug.mount
drwxr-xr-x.  2 root root 0 12. Jul 06:36 sys-kernel-tracing.mount
drwxr-xr-x. 32 root root 0 12. Jul 11:29 system.slice
drwxr-xr-x.  4 root root 0 12. Jul 06:36 user.slice

mount | grep cgroup

cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot)

[hdonnay]

This is just logging that the process doesn't seem to be in a cpu control group, and so the process won't attempt to tweak some settings to stay within its quota. The log message could probably be changed from an error to a warn to reflect that better.

[hdonnay]

This should be addressed via #2093.