lssubsys

lssubsys [OPTION...] [SUBSYSTEM...]

SUBSYSTEM...
    Optionally specify one or more subsystem names to limit the output to only those subsystems. For example, lssubsys cpu memory will only show the mount points for the cpu and memory subsystems.

-m, --mount-point
    Display only the mount point of the cgroup filesystem, without the subsystem name. This is useful when you only need the path for scripting or quick reference.

-M PATH, --host-root=PATH
    Specify an alternate host root directory. This is useful in container environments or when inspecting cgroups of a chrooted system, allowing lssubsys to operate on a different root filesystem.

-h, --help
    Display a help message and exit.

-v, --version
    Output version information and exit.

The lssubsys command is a utility for inspecting the control group (cgroup) filesystem on a Linux system. It provides a simple way to list all currently mounted cgroup subsystems and their respective mount points. Cgroups are a fundamental Linux kernel feature used for organizing processes into hierarchical groups to manage and account for system resources like CPU, memory, I/O, and network bandwidth.

Each cgroup subsystem is responsible for managing a specific type of resource. For example, the cpu subsystem controls CPU allocation, and the memory subsystem manages memory usage. By default, lssubsys will output a list of each mounted subsystem along with its path in the filesystem, typically under /sys/fs/cgroup. This command is invaluable for system administrators and developers who need to understand how cgroups are configured on a system, verify proper subsystem mounting, or diagnose resource management issues, especially in environments utilizing containers or resource isolation.

lssubsys primarily interacts with the cgroup v1 API, where each subsystem can be mounted on its own hierarchy. In systems predominantly using cgroup v2 (the unified hierarchy), lssubsys might show fewer or no explicit subsystem mount points, as v2 consolidates all resources under a single mount (typically /sys/fs/cgroup). It requires the cgroup filesystem to be mounted, which is usually handled automatically by the operating system (e.g., via systemd). The command is part of the cgroup-tools package, which may need to be installed separately depending on your Linux distribution.

Linux supports two major versions of cgroups: cgroup v1 and cgroup v2. lssubsys is primarily designed for cgroup v1, where different subsystems (e.g., cpu, memory) can be mounted on separate, distinct hierarchies in the filesystem. In contrast, cgroup v2 introduces a unified hierarchy where all subsystems are managed under a single mount point (typically /sys/fs/cgroup). While v1 allows for more flexibility in some setups, v2 aims for a cleaner, more consistent resource management model. When operating on a system primarily using v2, lssubsys might not show the individual subsystem mounts as it would for v1, making its output less informative for pure v2 contexts.

When run without arguments or the --mount-point option, lssubsys typically outputs two columns: the cgroup subsystem name and its corresponding mount path.

Example:
cpu,cpuacct /sys/fs/cgroup/cpu,cpuacct
memory /sys/fs/cgroup/memory
pids /sys/fs/cgroup/pids
blkio /sys/fs/cgroup/blkio

This output directly shows which resource controllers are active and where their respective control files and directories can be found for further inspection or management.

The concept of control groups (cgroups) was initially developed by Google engineers (Paul Menage and Rohit Seth) as 'process containers' in 2006. It was renamed to cgroups in 2007 and merged into the Linux kernel mainline in version 2.6.24 in January 2008. The lssubsys command, along with other utilities in the cgroup-tools suite, emerged as essential tools for interacting with and managing these kernel features. Its importance grew significantly with the rise of containerization technologies like Docker and LXC, and the widespread adoption of systemd, all of which heavily leverage cgroups for resource isolation and management. The command has remained a stable utility for inspecting the cgroup setup, particularly for the cgroup v1 architecture.

cgroups(7), lscgroup(1), cgcreate(1), cgdelete(1), cgexec(1), cgget(1), cgset(1), systemd.resource-control(5)