mirror of https://github.com/mkerrisk/man-pages
716 lines
24 KiB
Groff
716 lines
24 KiB
Groff
.\" Copyright (C) 2015 Serge Hallyn <serge@hallyn.com>
|
|
.\" and Copyright (C) 2016 Michael Kerrisk <mtk.manpages@gmail.com>
|
|
.\"
|
|
.\" %%%LICENSE_START(VERBATIM)
|
|
.\" Permission is granted to make and distribute verbatim copies of this
|
|
.\" manual provided the copyright notice and this permission notice are
|
|
.\" preserved on all copies.
|
|
.\"
|
|
.\" Permission is granted to copy and distribute modified versions of this
|
|
.\" manual under the conditions for verbatim copying, provided that the
|
|
.\" entire resulting derived work is distributed under the terms of a
|
|
.\" permission notice identical to this one.
|
|
.\"
|
|
.\" Since the Linux kernel and libraries are constantly changing, this
|
|
.\" manual page may be incorrect or out-of-date. The author(s) assume no
|
|
.\" responsibility for errors or omissions, or for damages resulting from
|
|
.\" the use of the information contained herein. The author(s) may not
|
|
.\" have taken the same level of care in the production of this manual,
|
|
.\" which is licensed free of charge, as they might when working
|
|
.\" professionally.
|
|
.\"
|
|
.\" Formatted or processed versions of this manual, if unaccompanied by
|
|
.\" the source, must acknowledge the copyright and authors of this work.
|
|
.\" %%%LICENSE_END
|
|
.\"
|
|
.TH CGROUPS 7 2016-07-17 "Linux" "Linux Programmer's Manual"
|
|
.SH NAME
|
|
cgroups \- Linux control groups
|
|
.SH DESCRIPTION
|
|
Control cgroups, usually referred to as cgroups,
|
|
are a Linux kernel feature which allow processes to
|
|
be organized into hierarchical groups whose usage of
|
|
various types of resources can then be limited and monitored.
|
|
The kernel's cgroup interface is provided through
|
|
a pseudo-filesystem called cgroupfs.
|
|
Grouping is implemented in the core cgroup kernel code,
|
|
while resource tracking and limits are implemented in
|
|
a set of per-resource-type subsystems (memory, CPU, and so on).
|
|
.\"
|
|
.SS Terminology
|
|
A
|
|
.I cgroup
|
|
is a collection of processes that are bound to a set of
|
|
limits or parameters defined via the cgroup filesystem.
|
|
|
|
A
|
|
.I subsystem
|
|
is a kernel component that modifies the behavior of
|
|
the processes in a cgroup.
|
|
Various subsystems have been implemented, making it possible to do things
|
|
such as limiting the amount of CPU time and memory available to a cgroup,
|
|
accounting for the CPU time used by a cgroup,
|
|
and freezing and resuming execution of the processes in a cgroup.
|
|
Subsystems are sometimes also known as
|
|
.IR "resource controllers"
|
|
(or simply, controllers).
|
|
|
|
The cgroups for a controller are arranged in a
|
|
.IR hierarchy .
|
|
This hierarchy is defined by creating, removing, and
|
|
renaming subdirectories within the cgroup filesystem.
|
|
At each level of the hierarchy, attributes (e.g., limits) can be defined.
|
|
The limits, control, and accounting provided by cgroups generally have
|
|
effect throughout the subhierarchy underneath the cgroup where the
|
|
attributes are defined.
|
|
Thus, for example, the limits placed on
|
|
a cgroup at a higher level in the hierarchy cannot be exceeded
|
|
by descendant cgroups.
|
|
.\"
|
|
.SS Cgroups version 1 and version 2
|
|
The initial release of the cgroups implementation was in Linux 2.6.24.
|
|
Over time, various cgroup controllers have been added
|
|
to allow the management of various types of resources.
|
|
However, the development of these controllers was largely uncoordinated,
|
|
with the result that many inconsistencies arose between controllers
|
|
and management of the cgroup hierarchies became rather complex.
|
|
(A longer description of these problems can be found in
|
|
the kernel source file
|
|
.IR Documentation/cgroup\-v2.txt .)
|
|
|
|
Because of the problems with the initial cgroups implementation
|
|
(cgroups version 1),
|
|
starting in Linux 3.10, work began on a new,
|
|
orthogonal implementation to remedy these problems.
|
|
Initially marked experimental, and hidden behind the
|
|
.I "\-o\ __DEVEL__sane_behavior"
|
|
mount option, the new version (cgroups version 2)
|
|
was eventually made official with the release of Linux 4.5.
|
|
Differences between the two versions are described in the text below.
|
|
|
|
Although cgroups v2 is intended as a replacement for cgroups v1,
|
|
the older system continues to exist
|
|
(and for compatibility reasons is unlikely to be removed).
|
|
Currently, cgroups v2 implements only a subset of the controllers
|
|
available in cgroups v1.
|
|
The two systems are implemented so that both v1 controllers and
|
|
v2 controllers can be mounted on the same system.
|
|
Thus, for example, it is possible to use those controllers
|
|
that are supported under version 2,
|
|
while also using version 1 controllers
|
|
where version 2 does not yet support those controllers.
|
|
The only restriction here is that a controller can't be simultaneously
|
|
employed in both a cgroups v1 hierarchy and in the cgroups v2 hierarchy.
|
|
.\"
|
|
.SS Cgroups version 1
|
|
Under cgroups v1, each controller may be mounted against a separate
|
|
cgroup filesystem that provides its own hierarchical organization of the
|
|
processes on the system.
|
|
It is also possible comount multiple (or even all) cgroups v1 controllers
|
|
against the same cgroup filesystem, meaning that the comounted controllers
|
|
manage the same hierarchical organization of processes.
|
|
|
|
For each mounted hierarchy,
|
|
the directory tree mirrors the control group hierarchy.
|
|
Each control group is represented by a directory, with each of its child
|
|
control cgroups represented as a child directory.
|
|
For instance,
|
|
.IR /user/joe/1.session
|
|
represents control group
|
|
.IR 1.session ,
|
|
which is a child of cgroup
|
|
.IR joe ,
|
|
which is a child of
|
|
.IR /user .
|
|
Under each cgroup directory is a set of files which can be read or
|
|
written to, reflecting resource limits and a few general cgroup
|
|
properties.
|
|
|
|
In addition, in cgroups v1,
|
|
cgroups can be mounted with no bound controller, in which case
|
|
they serve only to track processes.
|
|
(See the discussion of release notification below.)
|
|
An example of this is the
|
|
.I name=systemd
|
|
cgroup which is used by
|
|
.BR systemd (1)
|
|
to track services and user sessions.
|
|
.\"
|
|
.SS Tasks (threads) versus processes
|
|
In cgroups v1, a distinction is drawn between
|
|
.I processes
|
|
and
|
|
.IR tasks .
|
|
In this view, a process can consist of multiple tasks
|
|
(more commonly called threads, from a user-space perspective,
|
|
and called such in the remainder of this man page).
|
|
In cgroups v1, it is possible to independently manipulate
|
|
the cgroup memberships of the threads in a process.
|
|
Because this ability caused certain problems,
|
|
.\" FIXME Add some text describing why this was a problem.
|
|
the ability to independently manipulate the cgroup memberships
|
|
of the threads in a process has been removed in cgroups v2.
|
|
Cgroups v2 allows manipulation of cgroup membership only for processes
|
|
(which has the effect of changing the cgroup membership of
|
|
all threads in the process).
|
|
.\"
|
|
.SS Mounting v1 controllers
|
|
The use of cgroups requires a kernel built with the
|
|
.BR CONFIG_CGROUP\option.
|
|
In addition, each of the v1 controllers has an associated
|
|
configuration option that must be set in order to employ that controller.
|
|
|
|
In order to use a v1 controller,
|
|
it must be mounted against a cgroup filesystem.
|
|
The usual place for such mounts is under a tmpfs filesystem mounted at
|
|
.IR /sys/fs/cgroup .
|
|
Thus, one might mount the
|
|
.I cpu
|
|
controller as follows:
|
|
|
|
.nf
|
|
.in +4n
|
|
mount \-t cgroup \-o cpu none /sys/fs/cgroup/cpu
|
|
.in
|
|
.fi
|
|
|
|
It is possible to comount multiple controllers against the same hierarchy.
|
|
For example, here the
|
|
.IR cpu
|
|
and
|
|
.IR cpuacct
|
|
controllers are comounted against a single hierarchy:
|
|
|
|
.nf
|
|
.in +4n
|
|
mount \-t cgroup \-o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct
|
|
.in
|
|
.fi
|
|
|
|
Comounting controllers has the effect that a process is in the same cgroup for
|
|
all of the comounted controllers.
|
|
Separately mounting controllers allows a process to
|
|
be in cgroup
|
|
.I /foo1
|
|
for one controller while being in
|
|
.I /foo2/foo3
|
|
for another.
|
|
|
|
It is possible to comount all v1 controllers against the same hierarchy:
|
|
|
|
.nf
|
|
.in +4n
|
|
mount \-t cgroup \-o all cgroup /sys/fs/cgroup
|
|
.in
|
|
.fi
|
|
|
|
(One can achieve the same result by omitting
|
|
.IR "\-o all" ,
|
|
since it is the default if no controllers are explicitly specified.)
|
|
|
|
It is not possible to mount the same controller
|
|
against multiple cgroup hierarchies.
|
|
For example, it is not possible to mount both the
|
|
.I cpu
|
|
and
|
|
.I cpuacct
|
|
controllers against one hierarchy, and to mount the
|
|
.I cpu
|
|
controller alone against another hierarchy.
|
|
It is possible to create multiple mount points with exactly
|
|
the same set of comounted controllers.
|
|
However, in this case all that results is multiple mount points
|
|
providing a view of the same hierarchy.
|
|
|
|
Note that on many systems, the v1 controllers are automatically mounted under
|
|
.IR /sys/fs/cgroup ;
|
|
in particular,
|
|
.BR systemd (1)
|
|
automatically creates such mount points.
|
|
.\"
|
|
.SS Cgroups version 1 controllers
|
|
Each of the cgroups version 1 controllers is governed
|
|
by a kernel configuration option (listed below).
|
|
Additionally, the availability of the cgroups feature is governed by the
|
|
.BR CONFIG_CGROUPS
|
|
kernel configuration option.
|
|
.TP
|
|
.IR cpu " (since Linux 2.6.24; " \fBCONFIG_CGROUP_SCHED\fP )
|
|
Cgroups can be guaranteed a minimum number of "CPU shares"
|
|
when a system is busy.
|
|
This does not limit a cgroup's CPU usage if the CPUs are not busy.
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/scheduler/sched\-bwc.txt .
|
|
.TP
|
|
.IR cpuacct " (since Linux 2.6.24; " \fBCONFIG_CGROUP_CPUACCT\fP )
|
|
This provides accounting for CPU usage by groups of processes.
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/cgroup\-v1/cpuacct.txt .
|
|
.TP
|
|
.IR cpuset " (since Linux 2.6.24; " \fBCONFIG_CPUSETS\fP )
|
|
This cgroup can be used to bind the processes in a cgroup to
|
|
a specified set of CPUs and NUMA nodes.
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/cgroup\-v1/cpusets.txt .
|
|
.TP
|
|
.IR memory " (since Linux 2.6.25; " \fBCONFIG_MEMCG\fP )
|
|
The memory controller supports reporting and limiting of process memory, kernel
|
|
memory, and swap used by cgroups.
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/cgroup\-v1/memory.txt .
|
|
.TP
|
|
.IR devices " (since Linux 2.6.26; " \fBCONFIG_CGROUP_DEVICE\fP )
|
|
This supports controlling which processes may create (mknod) devices as
|
|
well as open them for reading or writing.
|
|
The policies may be specified as whitelists and blacklists.
|
|
Hierarchy is enforced, so new rules must not
|
|
violate existing rules for the target or ancestor cgroups.
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/cgroup-v1/devices.txt .
|
|
.TP
|
|
.IR freezer " (since Linux 2.6.28; " \fBCONFIG_CGROUP_FREEZER\fP )
|
|
The
|
|
.IR freezer
|
|
cgroup can suspend and restore (resume) all processes in a cgroup.
|
|
Freezing a cgroup
|
|
.I /A
|
|
also causes its children, for example, processes in
|
|
.IR /A/B ,
|
|
to be frozen.
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/cgroup-v1/freezer-subsystem.txt .
|
|
.TP
|
|
.IR net_cls " (since Linux 2.6.29; " \fBCONFIG_CGROUP_NET_CLASSID\fP )
|
|
This places a classid, specified for the cgroup, on network packets
|
|
created by a cgroup.
|
|
These classids can then be used in firewall rules,
|
|
as well as used to shape traffic using
|
|
.BR tc (8).
|
|
This applies only to packets
|
|
leaving the cgroup, not to traffic arriving at the cgroup.
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/cgroup-v1/net_cls.txt .
|
|
.TP
|
|
.IR blkio " (since Linux 2.6.33; " \fBCONFIG_BLK_CGROUP\fP )
|
|
The
|
|
.I blkio
|
|
cgroup controls and limits access to specified block devices by
|
|
applying IO control in the form of throttling and upper limits against leaf
|
|
nodes and intermediate nodes in the storage hierarchy.
|
|
|
|
Two policies are available.
|
|
The first is a proportional-weight time-based division
|
|
of disk implemented with CFQ.
|
|
This is in effect for leaf nodes using CFQ.
|
|
The second is a throttling policy which specifies
|
|
upper I/O rate limits on a device.
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/cgroup-v1/blkio-controller.txt .
|
|
.TP
|
|
.IR perf_event " (since Linux 2.6.39; " \fBCONFIG_CGROUP_PERF\fP )
|
|
This controller allows
|
|
.I perf
|
|
monitoring of the set of processes grouped in a cgroup.
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/perf-record.txt .
|
|
.TP
|
|
.IR net_prio " (since Linux 3.3; " \fBCONFIG_CGROUP_NET_PRIO\fP )
|
|
This allows priorities to be specified, per network interface, for cgroups.
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/cgroup-v1/net_prio.txt .
|
|
.TP
|
|
.IR hugetlb " (since Linux 3.5; " \fBCONFIG_CGROUP_HUGETLB\fP )
|
|
This supports limiting the use of huge pages by cgroups.
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/cgroup-v1/hugetlb.txt .
|
|
.TP
|
|
.IR pids " (since Linux 4.3; " \fBCONFIG_CGROUP_PIDS\fP )
|
|
This controller permits limiting the number of process that may be created
|
|
in a cgroup (and its descendants).
|
|
|
|
Further information can be found in the kernel source file
|
|
.IR Documentation/cgroup-v1/pids.txt .
|
|
.\"
|
|
.SS Creating cgroups and moving processes
|
|
A cgroup filesystem initially contains a single root cgroup, '/',
|
|
which all processes belong to.
|
|
A new cgroup is created by creating a directory in the cgroup filesystem:
|
|
|
|
mkdir /sys/fs/cgroup/cpu/cg1
|
|
|
|
This creates a new empty cgroup.
|
|
|
|
A process may be moved to this cgroup by writing its PID into the cgroup's
|
|
.I cgroup.procs
|
|
file:
|
|
|
|
echo $$ > /sys/fs/cgroup/cpu/cg1/cgroup.procs
|
|
|
|
Only one PID at a time should be written to this file.
|
|
|
|
Writing the value 0 to a
|
|
.IR cgroup.procs
|
|
file causes the writing process to be moved to the corresponding cgroup.
|
|
|
|
When writing a PID into the
|
|
.IR cgroup.procs ,
|
|
all threads in the process are moved into the new cgroup at once.
|
|
|
|
Within a hierarchy, a process can be a member of exactly one cgroup.
|
|
Writing a process's PID to a
|
|
.IR cgroup.procs
|
|
file automatically removes it from the cgroup of
|
|
which it was previously a member.
|
|
|
|
The
|
|
.I cgroup.procs
|
|
file can be read to obtain a list of the processes that are
|
|
members of a cgroup.
|
|
The returned list of PIDs is not guaranteed to be in order.
|
|
Nor is it guaranteed to be free of duplicates.
|
|
(For example, a PID may be recycled while reading from the list.)
|
|
|
|
In cgroups v1 (but not cgroups v2), an individual thread can be moved to
|
|
another cgroup by writing its thread ID
|
|
(i.e., the kernel thread ID returned by
|
|
.BR clone (2)
|
|
and
|
|
.BR gettid (2))
|
|
to the
|
|
.IR tasks
|
|
file in a cgroup directory.
|
|
This file can be read to discover the set of threads
|
|
that are members of the cgroup.
|
|
This file is not present in cgroup v2 directories.
|
|
.\"
|
|
.SS Removing cgroups
|
|
To remove a cgroup,
|
|
it must first have no child cgroups and contain no (nonzombie) processes.
|
|
So long as that is the case, one can simply
|
|
remove the corresponding directory pathname.
|
|
Note that files in a cgroup directory cannot and need not be
|
|
removed.
|
|
.\"
|
|
.SS Cgroups v1 release notification
|
|
Two files can be used to determine whether the kernel provides
|
|
notifications when a cgroup becomes empty.
|
|
A cgroup is considered to be empty when it contains no child
|
|
cgroups and no member processes.
|
|
|
|
A special file in the root directory of each cgroup hierarchy,
|
|
.IR release_agent ,
|
|
can be used to register the pathname of a program that may be invoked when
|
|
a cgroup in the hierarchy becomes empty.
|
|
The pathname of the newly empty cgroup (relative to the cgroup mount point)
|
|
is provided as the sole command-line argument when the
|
|
.IR release_agent
|
|
program is invoked.
|
|
The
|
|
.IR release_agent
|
|
program might remove the cgroup directory,
|
|
or perhaps repopulate with a process.
|
|
|
|
The default value of the
|
|
.IR release_agent
|
|
file is empty, meaning that no release agent is invoked.
|
|
|
|
Whether or not the
|
|
.IR release_agent
|
|
program is invoked when a particular cgroup becomes empty is determined
|
|
by the value in the
|
|
.IR notify_on_release
|
|
file in the corresponding cgroup directory.
|
|
If this file contains the value 0, then the
|
|
.IR release_agent
|
|
program is not invoked.
|
|
If it contains the value 1, the
|
|
.IR release_agent
|
|
program is invoked.
|
|
The default value for this file in the root cgroup is 0.
|
|
At the time when a new cgroup is created,
|
|
the value in this file is inherited from the corresponding file
|
|
in the parent cgroup.
|
|
.\"
|
|
.SS Cgroups version 2
|
|
In cgroups v2,
|
|
all mounted controllers reside in a single unified hierarchy.
|
|
While (different) controllers may be simultaneously
|
|
mounted under the v1 and v2 hierarchies,
|
|
it is not possible to mount the same controller simultaneously
|
|
under both the v1 and the v2 hierarchies.
|
|
|
|
The new behaviors in cgroups v2 are summarized here,
|
|
and in some cases elaborated in the following subsections.
|
|
.IP 1. 3
|
|
Cgroups v2 provides a unified hierarchy against
|
|
which all controllers are mounted.
|
|
.IP 2.
|
|
"Internal" processes are not permitted.
|
|
With the exception of the root cgroup, processes may reside
|
|
only in leaf nodes (cgroups that do not themselves contain child cgroups).
|
|
.IP 3.
|
|
Active cgroups must be specified via the files
|
|
.IR cgroup.controllers
|
|
and
|
|
.IR cgroup.subtree_control .
|
|
.IP 4.
|
|
The
|
|
.I tasks
|
|
file has been removed.
|
|
In addition, the
|
|
.I cgroup.clone_children
|
|
file that is employed by the
|
|
.I cpuset
|
|
controller has been removed.
|
|
.IP 5.
|
|
An improved mechanism for notification of empty cgroups is provided by the
|
|
.IR cgroup.events
|
|
file.
|
|
.PP
|
|
For more changes, see the
|
|
.I Documentation/cgroup-v2.txt
|
|
file in the kernel source.
|
|
.\"
|
|
.SS Cgroups v2 unified hierarchy
|
|
In cgroups v1, the ability to mount different controllers
|
|
against different hierarchies was intended to allow great flexibility
|
|
for application design.
|
|
In practice, though, the flexibility turned out to less useful than expected,
|
|
and in many cases added complexity.
|
|
Therefore, in cgroups v2,
|
|
all available controllers are mounted against a single hierarchy.
|
|
The available controllers are automatically mounted,
|
|
meaning that it is not necessary (or possible) to specify the controllers
|
|
when mounting the cgroup v2 filesystem using a command such as the following:
|
|
|
|
mount -t cgroup2 none /mnt/cgroup2
|
|
|
|
A cgroup v2 controller is available only if it is not currently in use
|
|
via a mount against a cgroup v1 hierarchy.
|
|
Or, to put things another way, it is not possible to employ
|
|
the same controller against both a v1 hierarchy and the unified v2 hierarchy.
|
|
.\"
|
|
.SS Cgroups v2 """no internal processes""" rule
|
|
With the exception of the root cgroup, processes may reside
|
|
only in leaf nodes (cgroups that do not themselves contain child cgroups).
|
|
This avoids the need to decide how to partition resources between
|
|
processes which are members of cgroup A and processes in child cgroups of A.
|
|
|
|
For instance, if cgroup
|
|
.I /cg1/cg2
|
|
exists, then a process may reside in
|
|
.IR /cg1/cg2 ,
|
|
but not in
|
|
.IR /cg1 .
|
|
This is to avoid an ambiguity in cgroups v1
|
|
with respect to the delegation of resources between processes in
|
|
.I /cg1
|
|
and its child cgroups.
|
|
The recommended approach in cgroups v2 is to create a subdirectory called
|
|
.I leaf
|
|
for any nonleaf cgroup which should contain processes, but no child cgroups.
|
|
Thus, processes which previously would have gone into
|
|
.I /cg1
|
|
would now go into
|
|
.IR /cg1/leaf .
|
|
This has the advantage of making explicit
|
|
the relationship between processes in
|
|
.I /cg1/leaf
|
|
and
|
|
.IR /cg1 's
|
|
other children.
|
|
.\"
|
|
.SS Cgroups v2 subtree control
|
|
When a cgroup
|
|
.I A/b
|
|
is created, its
|
|
.IR cgroup.controllers
|
|
file contains the list of controllers which were active in its parent, A.
|
|
This is the list of controllers which are available to this cgroup.
|
|
No controllers are active until they are enabled through the
|
|
.IR cgroup.subtree_control
|
|
file, by writing the list of space-delimited names of the controllers,
|
|
each preceded by '+' (to enable) or '\-' (to disable).
|
|
If the
|
|
.I freezer
|
|
controller is not enabled in
|
|
.IR /A/B ,
|
|
then it cannot be enabled in
|
|
.IR /A/B/C .
|
|
.\"
|
|
.SS Cgroups v2 cgroup.events file
|
|
With cgroups v2, a new mechanism is provided to obtain notification
|
|
about when a cgroup becomes empty.
|
|
The cgroups v1
|
|
.IR release_agent
|
|
and
|
|
.IR notify_on_release
|
|
files are removed, and replaced by a new, more general-purpose file,
|
|
.IR cgroup.events .
|
|
This file contains key-value pairs
|
|
(delimited by newline characters, with the key and value separated by spaces)
|
|
that identify events or state for a cgroup.
|
|
Currently, only one key appears in this file,
|
|
.IR populated ,
|
|
which has either the value 0,
|
|
meaning that the cgroup (and its descendants)
|
|
contain no (nonzombie) processes,
|
|
or 1, meaning that the cgroup contains member processes.
|
|
|
|
The
|
|
.IR cgroup.events
|
|
file can be monitored, in order to receive notification when a cgroup
|
|
transitions between the populated and unpopulated states (or vice versa).
|
|
When monitoring this file using
|
|
.BR inotify (7),
|
|
transitions generate
|
|
.BR IN_MODIFY
|
|
events, and when monitoring the file using
|
|
.BR poll (2),
|
|
transitions generate
|
|
.B POLLPRI
|
|
events.
|
|
|
|
The cgroups v2
|
|
.IR notify_on_release
|
|
mechanism offers at least two advantages over the cgroups v1
|
|
.IR release_agent
|
|
mechanism.
|
|
First, it allows for cheaper notification,
|
|
since a single process can monitor multiple
|
|
.IR cgroup.events
|
|
files.
|
|
By contrast, the cgroups v1 mechanism requires the creation
|
|
of a process for each notification.
|
|
Second, notification can be delegated to a process that lives inside
|
|
a container associated with the newly empty cgroup.
|
|
.\"
|
|
.SS /proc files
|
|
.TP
|
|
.IR /proc/cgroups " (since Linux 2.6.24)"
|
|
This file contains information about the controllers
|
|
that are compiled into the kernel.
|
|
An example of the contents of this file (reformatted for readability)
|
|
is the following:
|
|
|
|
.nf
|
|
.in +4n
|
|
#subsys_name hierarchy num_cgroups enabled
|
|
cpuset 4 1 1
|
|
cpu 8 1 1
|
|
cpuacct 8 1 1
|
|
blkio 6 1 1
|
|
memory 3 1 1
|
|
devices 10 84 1
|
|
freezer 7 1 1
|
|
net_cls 9 1 1
|
|
perf_event 5 1 1
|
|
net_prio 9 1 1
|
|
hugetlb 0 1 0
|
|
pids 2 1 1
|
|
.in
|
|
.fi
|
|
|
|
The fields in this file are, from left to right:
|
|
.RS
|
|
.IP 1. 3
|
|
The name of the controller.
|
|
.IP 2.
|
|
The unique ID of the cgroup hierarchy on which this controller is mounted.
|
|
If multiple cgroups v1 controllers are bound to the same hierarchy,
|
|
then each will show the same hierarchy ID in this field.
|
|
The value in this field will be 0 if:
|
|
.RS 5
|
|
.IP a) 3
|
|
the controller is not mounted on a cgroups v1 hierarchy;
|
|
.IP b)
|
|
the controller is bound to the cgroups v2 single unified hierarchy; or
|
|
.IP c)
|
|
the controller is disabled (see below).
|
|
.RE
|
|
.IP 3.
|
|
The number of control groups in this hierarchy using this controller.
|
|
.IP 4.
|
|
This field contains the value 1 if this controller is enabled,
|
|
or 0 if it has been disabled (via the
|
|
.IR cgroup_disable
|
|
kernel command-line boot parameter).
|
|
.RE
|
|
.TP
|
|
.IR /proc/[pid]/cgroup " (since Linux 2.6.24)"
|
|
This file describes control groups to which the process
|
|
with the corresponding PID belongs.
|
|
The displayed information differs for
|
|
cgroups version 1 and version 2 hierarchies.
|
|
|
|
For each cgroup hierarchy of which the process is a member,
|
|
there is one entry containing three
|
|
colon-separated fields of the form:
|
|
|
|
hierarchy-ID:controller-list:cgroup-path
|
|
|
|
For example:
|
|
.nf
|
|
.ft CW
|
|
|
|
5:cpuacct,cpu,cpuset:/daemons
|
|
.ft
|
|
.fi
|
|
.IP
|
|
The colon-separated fields are, from left to right:
|
|
.RS
|
|
.IP 1. 3
|
|
For cgroups version 1 hierarchies,
|
|
this field contains a unique hierarchy ID number
|
|
that can be matched to a hierarchy ID in
|
|
.IR /proc/cgroups .
|
|
For the cgroups version 2 hierarchy, this field contains the value 0.
|
|
.IP 2.
|
|
For cgroups version 1 hierarchies,
|
|
this field contains a comma-separated list of the controllers
|
|
bound to the hierarchy.
|
|
For the cgroups version 2 hierarchy, this field is empty.
|
|
.IP 3.
|
|
This field contains the pathname of the control group in the hierarchy
|
|
to which the process belongs.
|
|
This pathname is relative to the mount point of the hierarchy.
|
|
.RE
|
|
.SH ERRORS
|
|
The following errors can occur for
|
|
.BR mount (2):
|
|
.TP
|
|
.B EBUSY
|
|
An attempt to mount a cgroup version 1 filesystem specified neither the
|
|
.I name=
|
|
option (to mount a named hierarchy) nor a controller name (or
|
|
.IR all ).
|
|
.SH NOTES
|
|
A child process created via
|
|
.BR fork (2)
|
|
inherits its parent's cgroup memberships.
|
|
A process's cgroup memberships are preserved across
|
|
.BR execve (2).
|
|
.SH SEE ALSO
|
|
.BR prlimit (1),
|
|
.BR systemd (1),
|
|
.BR clone (2),
|
|
.BR ioprio_set (2),
|
|
.BR perf_event_open (2),
|
|
.BR setrlimit (2),
|
|
.BR cgroup_namespaces (7),
|
|
.BR cpuset (7),
|
|
.BR namespaces (7),
|
|
.BR sched (7),
|
|
.BR user_namespaces (7)
|