You will learn how to identify the cpuset containing a running Linux process, and how to check the CPUs that the kernel currently allows it to use. The inspection is read-only: these commands do not move a process, change affinity or alter a service.
Allow about five minutes. You need a shell on Linux and a process ID that you are allowed to inspect. Root is not normally required for your own processes. A process owned by another account may disappear while you inspect it, or its procfs files may be restricted by the host's privacy settings.
/proc/PID/cpuset answers "which cpuset contains this process?" It prints the path of that process's cpuset directory, relative to the root of the cpuset filesystem. It does not print a CPU number or a CPU range.
The separate Cpus_allowed_list line in /proc/PID/status answers "which logical CPUs may this process run on?" The two values are related, but they are not interchangeable. A process can also have a narrower per-process CPU affinity inside the CPUs permitted by its cpuset.
Start with your own process. The self component is a procfs shortcut, so there is no stale PID to replace while this command runs.
$ cat /proc/self/cpuset
/user.slice
$ awk '/^Cpus_allowed_list:/ { print $2 }' /proc/self/status
0-7The exact output is host-specific. A result such as /user.slice is a cpuset path, not a claim that the process can run only on CPU 0. The CPU list comes from the second command. On a different system the cpuset path may be /, or another hierarchy path.
If cat reports that the file does not exist, check that you are on Linux and that procfs is mounted:
$ test -r /proc/self/cpuset && echo "proc cpuset entry is readable"
proc cpuset entry is readableFor a long-lived service, replace PID with the numeric process ID. Keep the two reads together so you can compare the cpuset path and allowed CPU list from roughly the same moment.
$ PID=12345
$ printf 'cpuset: '
$ cat "/proc/$PID/cpuset"
$ awk '/^Cpus_allowed_list:/ { print "allowed CPUs: " $2 }' "/proc/$PID/status"
cpuset: /batch/job-a
allowed CPUs: 2-3
These are ordinary, unprivileged reads. Do not add sudo automatically: elevated access can expose more processes, but it does not make a vanished PID valid. If the process exits between commands, repeat the check with a live PID. For a reproducible test, create a short-lived process and capture its PID before inspecting it:
$ sleep 30 &
$ PID=$!
$ printf 'PID %s, cpuset: ' "$PID"
$ cat "/proc/$PID/cpuset"
$ kill "$PID"
[1]+ Terminated sleep 30The final kill stops only the test process you started. If you skip that line, the sleep exits by itself after 30 seconds. Never substitute a production PID in a command intended to stop the test process.
A cpuset is a kernel control for CPU and memory-node placement. Every process belongs to exactly one cpuset. The cpuset hierarchy is represented by directories in the cpuset interface, and child sets normally describe a subset of the parent's resources. The path is therefore useful when diagnosing a scheduler, container or service placement decision.
The allowed CPU list is the more direct answer when you need to know where a process may execute. It can be constrained by more than one mechanism, including the process's CPU affinity and the cpuset. The effective result can be narrower than the cpuset's available CPUs. Reading /proc/PID/status is therefore a verification step, not a substitute for understanding the policy that placed the process there.
On modern hosts you may see a cgroup v2 mount at /sys/fs/cgroup while still using the procfs interface above. Do not infer the mount layout from the cpuset path. The proc entry reports the kernel's cpuset association; it does not print a cgroup v2 filesystem path.
/ and /user.slice are locations in a hierarchy. Read Cpus_allowed_list for CPU numbers.ps -p "$PID" before retrying./proc/self/cpuset without changing state./proc/PID/cpuset./proc/PID/status.