Merge pull request #15403 from sstosh/cgroups-cpuset

[CI:DOCS] Update how to enable resource limit delegation

docs/source/markdown/options/cpu-period.md

@@ -5,6 +5,6 @@ duration in microseconds. Once the container's CPU quota is used up, it will
 not be scheduled to run until the current period ends. Defaults to 100000
 microseconds.
 
-On some systems, changing the CPU limits may not be allowed for non-root
+On some systems, changing the resource limits may not be allowed for non-root
 users. For more details, see
-https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-cpu-limits-fails-with-a-permissions-error
+https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

docs/source/markdown/options/cpu-quota.md

@@ -7,6 +7,6 @@ CPU resource. The limit is a number in microseconds. If a number is provided,
 the container will be allowed to use that much CPU time until the CPU period
 ends (controllable via **--cpu-period**).
 
-On some systems, changing the CPU limits may not be allowed for non-root
+On some systems, changing the resource limits may not be allowed for non-root
 users. For more details, see
-https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-cpu-limits-fails-with-a-permissions-error
+https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

docs/source/markdown/options/cpu-shares.md

@@ -33,3 +33,7 @@ this can result in the following division of CPU shares:
 | 100  |  C0         | 0       | 100% of CPU0 |
 | 101  |  C1         | 1       | 100% of CPU1 |
 | 102  |  C1         | 2       | 100% of CPU2 |
+
+On some systems, changing the resource limits may not be allowed for non-root
+users. For more details, see
+https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

docs/source/markdown/options/cpuset-cpus.md

@@ -3,3 +3,7 @@
 CPUs in which to allow execution. Can be specified as a comma-separated list
 (e.g. **0,1**), as a range (e.g. **0-3**), or any combination thereof
 (e.g. **0-3,7,11-15**).
+
+On some systems, changing the resource limits may not be allowed for non-root
+users. For more details, see
+https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

docs/source/markdown/options/cpuset-mems.md

@@ -6,3 +6,7 @@ NUMA systems.
 If there are four memory nodes on the system (0-3), use **--cpuset-mems=0,1**
 then processes in the container will only use memory from the first
 two memory nodes.
+
+On some systems, changing the resource limits may not be allowed for non-root
+users. For more details, see
+https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

troubleshooting.md

@@ -678,23 +678,28 @@ $ podman run --rootfs /path/to/rootfs:O ....
 Modifications to the mount point are destroyed when the container
 finishes executing, similar to a tmpfs mount point being unmounted.
 
-### 26) Running containers with CPU limits fails with a permissions error
+### 26) Running containers with resource limits fails with a permissions error
 
-On some systemd-based systems, non-root users do not have CPU limit delegation
-permissions. This causes setting CPU limits to fail.
+On some systemd-based systems, non-root users do not have resource limit delegation
+permissions. This causes setting resource limits to fail.
 
 #### Symptom
 
-Running a container with a CPU limit options such as `--cpus`, `--cpu-period`,
-or `--cpu-quota` will fail with an error similar to the following:
+Running a container with a resource limit options will fail with an error similar to the following:
 
-    Error: opening file `cpu.max` for writing: Permission denied: OCI runtime permission denied error
+`--cpus`, `--cpu-period`, `--cpu-quota`, `--cpu-shares`:
 
-This means that CPU limit delegation is not enabled for the current user.
+    Error: OCI runtime error: crun: the requested cgroup controller `cpu` is not available
+
+`--cpuset-cpus`, `--cpuset-mems`:
+
+    Error: OCI runtime error: crun: the requested cgroup controller `cpuset` is not available
+
+This means that resource limit delegation is not enabled for the current user.
 
 #### Solution
 
-You can verify whether CPU limit delegation is enabled by running the following command:
+You can verify whether resource limit delegation is enabled by running the following command:
 
 ```console
 $ cat "/sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllers"
@@ -704,19 +709,19 @@ Example output might be:
 
     memory pids
 
-In the above example, `cpu` is not listed, which means the current user does
-not have permission to set CPU limits.
+In the above example, `cpu` and `cpuset` are not listed, which means the current user does
+not have permission to set CPU or CPUSET limits.
 
-If you want to enable CPU limit delegation for all users, you can create the
+If you want to enable CPU or CPUSET limit delegation for all users, you can create the
 file `/etc/systemd/system/user@.service.d/delegate.conf` with the contents:
 
 ```ini
 [Service]
-Delegate=memory pids cpu io
+Delegate=memory pids cpu cpuset
 ```
 
-After logging out and logging back in, you should have permission to set CPU
-limits.
+After logging out and logging back in, you should have permission to set
+CPU and CPUSET limits.
 
 ### 26) `exec container process '/bin/sh': Exec format error` (or another binary than `bin/sh`)