.\" -*- coding: UTF-8 -*-
.\" Copyright (C) 2015 Serge Hallyn <serge@hallyn.com>
.\" and Copyright (C) 2016, 2017 Michael Kerrisk <mtk.manpages@gmail.com>
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH cgroups 7 "2 мая 2024 г." "Linux man\-pages 6.8" 
.SH ИМЯ
cgroups \- управляемые группы в Linux
.SH ОПИСАНИЕ
.\"
Управляемые cgroup\-ы, обычно называемые cgroups, это свойство ядра Linux,
которое позволяет объединять процессы в иерархические группы, и в этих
группах отслеживать и ограничивать разные типы ресурсов. Ядро предоставляет
интерфейс работы с cgroup\-ами через псевдо\-файловую систему, называемую
cgroupfs. Группировка реализована в базовой части ядра cgroup, а слежение за
ресурсами и ограничениями — в подсистемах самих ресурсов (память, ЦП и
т. п.).
.SS Терминология
\fIcgroup\fP — это набор процессов, которые связаны с набором ограничений или
параметров, определяемых через файловую систему cgroup.
.P
\fIsubsystem\fP — компонент ядра, который изменяет поведение процессов в
cgroup\-у. Реализованы различные подсистемы, они позволяют делать разные
вещи, например ограничивать количество времени ЦП и память доступную для
cgroup\-ы, подсчитывать время ЦП, используемое группой и останавливать и
возобновлять выполнение процессов в cgroup\-е. Подсистемы иногда также
называют \fIконтроллерами ресурсов\fP (или просто, контроллерами).
.P
.\"
Для контроллера cgroup\-ы упорядочены в \fIиерархию\fP. Иерархия определяется
посредством создания, удаления и переименования подкаталогов в файловой
системе cgroup. На каждом уровне иерархии можно задать атрибуты (например,
ограничения). Если атрибуты назначены, то ограничение, контроль и учёт,
предоставляемый cgroup\-ами, обычно, распространяется в иерархии по всем
нижестоящим элементам. То есть, например, ограничение, заданное на cgroup на
высшем уровне иерархии не может быть превышено в дочерних cgroup\-ах.
.SS "Cgroups версии 1 и 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 \fIDocumentation/admin\-guide/cgroup\-v2.rst\fP (or
\fIDocumentation/cgroup\-v2.txt\fP in Linux 4.17 and earlier).
.P
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 \fI\-o\ __DEVEL__sane_behavior\fP 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.  The file \fIcgroup.sane_behavior\fP, present in cgroups v1, is a
relic of this mount option.  The file always reports "0" and is only
retained for backward compatibility.
.P
.\"
Хотя cgroups v2 создавалась как замена cgroups v1, старая система всё ещё
существует (и для обеспечения совместимости её не хотелось бы удалять). В
настоящее время, в cgroups v2 реализованы не все контроллеры, доступные в
cgroups v1. Эти две системы реализованы таким образом, что контроллеры v1 и
v2 можно монтировать одновременно. То есть, например, можно не только
использовать контроллеры, поддерживаемые версией 2, но и использовать
контроллеры версии 1, которые пока не поддерживаются версией 2. Единственным
ограничением является то, что один и тот же контроллер не может быть запущен
одновременно в иерархии cgroups v1 и cgroups v2.
.SH "CGROUPS ВЕРСИИ 1"
В cgroups v1 каждый контроллер можно смонтировать в отдельную файловую
систему cgroup, которая представляет собой собственную иерархию процессов в
системе. Также возможно совместное монтирование нескольких (или даже всех)
контроллеров cgroups v1 в единую файловую систему cgroup, при этом совместно
смонтированные контроллеры управляют одной иерархией процессов.
.P
.\"
Для каждой смонтированной иерархии дерево каталогов отражает иерархию
управляемой группы. Каждая управляемая группа представляется каталогом,
каждый её потомок управляемой cgroups представляется дочерним
каталогом. Например, \fI/user/joe/1.session\fP представляет управляемую группу
\fI1.session\fP, которая является потомком cgroup \fIjoe\fP, которая является
потомком \fI/user\fP. В каждом каталоге cgroup есть набор файлов, доступных на
чтение и запись, через которые доступны ограничения ресурсов и другие общие
свойства cgroup.
.SS "Задачи (нити) и процессы"
В cgroups v1 \fIпроцессы\fP и \fIзадачи\fP различаются. Процесс может состоять из
нескольких задач (чаще всего называемых нитями, если смотреть из
пользовательского пространства, и так они будут называться далее в этой
справочной странице). В cgroups v1 возможно независимо управлять членством
cgroup для нитей процесса.
.P
.\"
В некоторых случаях способность cgroups v1  разделять нити по разным cgroups
вызывает проблемы. Например, это не имеет смысла для контроллера \fImemory\fP,
так как все нити процесса находятся в одном адресном пространстве. Из\-за
таких проблем способность независимого управления членством cgroup для нитей
процесса была удалена в первой реализации cgroups v2, но позже восстановлена
в более ограниченном виде (смотрите описание «режим нитей» ниже).
.SS "Монтирование контроллеров v1"
Для использования cgroups требуется собрать ядро с параметром
\fBCONFIG_CGROUP\fP. Также с каждым контроллером v1 связан параметр настройки,
который должен быть задан, если нужно работать с этим контроллером.
.P
Чтобы использовать контроллер a v1, его нужно смонтировать в файловую
систему cgroup. Обычно для этого используют файловую систему \fBtmpfs\fP(5),
смонтированную в \fI/sys/fs/cgroup\fP. Таким образом, можно смонтировать
контроллер \fIcpu\fP следующим образом:
.P
.in +4n
.EX
mount \-t cgroup \-o cpu none /sys/fs/cgroup/cpu
.EE
.in
.P
Можно смонтировать несколько контроллеров вместе в одной иерархии. Например,
так контроллеры \fIcpu\fP и \fIcpuacct\fP одновременно монтируются в одной
иерархии:
.P
.in +4n
.EX
mount \-t cgroup \-o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct
.EE
.in
.P
Для одновременно смонтированных контроллеров процесс находится в одной
cgroup всех одновременно смонтированных контроллеров. Отдельно
смонтированные контроллеры позволяют процессу находиться в cgroup \fI/foo1\fP
одного контроллера и в \fI/foo2/foo3\fP другого.
.P
Можно смонтировать все контроллеры v1 вместе в одной иерархии:
.P
.in +4n
.EX
mount \-t cgroup \-o all cgroup /sys/fs/cgroup
.EE
.in
.P
(Параметр \fI\-o all\fP можно опустить, так как по умолчанию монтируются все
контроллеры, если ни один не указан явно)
.P
It is not possible to mount the same controller against multiple cgroup
hierarchies.  For example, it is not possible to mount both the \fIcpu\fP and
\fIcpuacct\fP controllers against one hierarchy, and to mount the \fIcpu\fP
controller alone against another hierarchy.  It is possible to create
multiple mount 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.
.P
.\"
Note that on many systems, the v1 controllers are automatically mounted
under \fI/sys/fs/cgroup\fP; in particular, \fBsystemd\fP(1)  automatically creates
such mounts.
.SS "Размонтирование контроллеров v1"
Смонтированная файловая система cgroup может быть размонтирована с помощью
команды \fBumount\fP(8) как показано в этом примере:
.P
.in +4n
.EX
umount /sys/fs/cgroup/pids
.EE
.in
.P
.\"
\fIBut note well\fP: a cgroup filesystem is unmounted only if it is not busy,
that is, it has no child cgroups.  If this is not the case, then the only
effect of the \fBumount\fP(8)  is to make the mount invisible.  Thus, to ensure
that the mount is really removed, one must first remove all child cgroups,
which in turn can be done only after all member processes have been moved
from those cgroups to the root cgroup.
.SS "Контроллеры cgroups версии 1"
Все контроллеры cgroups версии 1 управляются параметрами настройки ядра
(список далее). Также, включение свойства cgroups управляется параметром
настройки ядра \fBCONFIG_CGROUPS\fP.
.TP 
\fIcpu\fP (начиная с 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.
For further information, see \fIDocumentation/scheduler/sched\-design\-CFS.rst\fP
(or \fIDocumentation/scheduler/sched\-design\-CFS.txt\fP in Linux 5.2 and
earlier).
.IP
In Linux 3.2, this controller was extended to provide CPU "bandwidth"
control.  If the kernel is configured with \fBCONFIG_CFS_BANDWIDTH\fP, then
within each scheduling period (defined via a file in the cgroup directory),
it is possible to define an upper limit on the CPU time allocated to the
processes in a cgroup.  This upper limit applies even if there is no other
competition for the CPU.  Further information can be found in the kernel
source file \fIDocumentation/scheduler/sched\-bwc.rst\fP (or
\fIDocumentation/scheduler/sched\-bwc.txt\fP in Linux 5.2 and earlier).
.TP 
\fIcpuacct\fP (начиная с Linux 2.6.24; \fBCONFIG_CGROUP_CPUACCT\fP)
Включает учёт использования ЦП группами процессов.
.IP
Further information can be found in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v1/cpuacct.rst\fP (or
\fIDocumentation/cgroup\-v1/cpuacct.txt\fP in Linux 5.2 and earlier).
.TP 
\fIcpuset\fP (начиная с Linux 2.6.24; \fBCONFIG_CPUSETS\fP)
Эту cgroup можно использовать для привязки процессов в cgroup к указанному
набору ЦП и узлов NUMA.
.IP
Further information can be found in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v1/cpusets.rst\fP (or
\fIDocumentation/cgroup\-v1/cpusets.txt\fP in Linux 5.2 and earlier).
.
.TP 
\fImemory\fP (начиная с Linux 2.6.25; \fBCONFIG_MEMCG\fP)
Контроллер памяти поддерживает учёт и ограничение памяти процесса, памяти
ядра и подкачки, используемой cgroups.
.IP
Further information can be found in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v1/memory.rst\fP (or
\fIDocumentation/cgroup\-v1/memory.txt\fP in Linux 5.2 and earlier).
.TP 
\fIdevices\fP (начиная с 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
allow\-lists and deny\-lists.  Hierarchy is enforced, so new rules must not
violate existing rules for the target or ancestor cgroups.
.IP
Further information can be found in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v1/devices.rst\fP (or
\fIDocumentation/cgroup\-v1/devices.txt\fP in Linux 5.2 and earlier).
.TP 
\fIfreezer\fP (начиная с Linux 2.6.28; \fBCONFIG_CGROUP_FREEZER\fP)
\fIfreezer\fP cgroup может приостанавливать и возобновлять работу всех
процессов в cgroup. Заморозка cgroup \fI/A\fP также влияет на её потомков,
например, процессы в \fI/A/B\fP тоже приостанавливаются.
.IP
Further information can be found in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v1/freezer\-subsystem.rst\fP (or
\fIDocumentation/cgroup\-v1/freezer\-subsystem.txt\fP in Linux 5.2 and earlier).
.TP 
\fInet_cls\fP (начиная с Linux 2.6.29; \fBCONFIG_CGROUP_NET_CLASSID\fP)
Помещает classid, задаваемые для cgroup, в сетевые пакеты, создаваемые
cgroup. Эти classid затем можно использовать в правилах межсетевого экрана,
а также для ограничения трафика с помощью \fBtc\fP(8). Применяется только к
пакетам, выходящим из cgroup, и не применяется к входящему трафику cgroup.
.IP
Further information can be found in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v1/net_cls.rst\fP (or
\fIDocumentation/cgroup\-v1/net_cls.txt\fP in Linux 5.2 and earlier).
.TP 
\fIblkio\fP (начиная с Linux 2.6.33; \fBCONFIG_BLK_CGROUP\fP)
\fIblkio\fP cgroup контролирует и ограничивает доступ к заданным блочным
устройствам, применяет управление вводом\-выводом посредством пропусков
(throttling) и ограничения сверху листовых узлов и и промежуточных узлов в
иерархии хранилища.
.IP
Доступно две стратегии. Первая: пропорционально взвешенное повременное
разделение диска, реализованная посредством CFQ. Влияет на листовые узлы с
помощью CFQ. Вторая: стратегия пропусков, которая задаётся верхним
ограничением скорости обмена с устройством.
.IP
Further information can be found in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v1/blkio\-controller.rst\fP (or
\fIDocumentation/cgroup\-v1/blkio\-controller.txt\fP in Linux 5.2 and earlier).
.TP 
\fIperf_event\fP (начиная с Linux 2.6.39; \fBCONFIG_CGROUP_PERF\fP)
Этот контроллер позволяет выполнять слежение \fIperf\fP за набором процессов,
сгруппированных в cgroup.
.IP
Further information can be found in the kernel source files
.TP 
\fInet_prio\fP (начиная с Linux 3.3; \fBCONFIG_CGROUP_NET_PRIO\fP)
Позволяет для cgroups задавать свой приоритет на каждый интерфейс.
.IP
Further information can be found in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v1/net_prio.rst\fP (or
\fIDocumentation/cgroup\-v1/net_prio.txt\fP in Linux 5.2 and earlier).
.TP 
\fIhugetlb\fP (начиная с Linux 3.5; \fBCONFIG_CGROUP_HUGETLB\fP)
Поддерживает ограничение cgroups на использование огромных страниц.
.IP
Further information can be found in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v1/hugetlb.rst\fP (or
\fIDocumentation/cgroup\-v1/hugetlb.txt\fP in Linux 5.2 and earlier).
.TP 
\fIpids\fP (начиная с Linux 4.3; \fBCONFIG_CGROUP_PIDS\fP)
Этот контроллер позволяет ограничивать количество процессов, которые могут
быть созданы в cgroup (и её потомках).
.IP
Further information can be found in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v1/pids.rst\fP (or
\fIDocumentation/cgroup\-v1/pids.txt\fP in Linux 5.2 and earlier).
.TP 
\fIrdma\fP (начиная с Linux 4.11; \fBCONFIG_CGROUP_RDMA\fP)
Контроллер RDMA позволяет ограничивать использование ресурсов RDMA/IB
определённой cgroup.
.IP
.\"
Further information can be found in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v1/rdma.rst\fP (or
\fIDocumentation/cgroup\-v1/rdma.txt\fP in Linux 5.2 and earlier).
.SS "Создание cgroups и перемещение процессов"
Первоначально, в файловой системе cgroup содержится только корневая cgroup,
«/», которой принадлежат все процессы. Новая cgroup создаётся посредством
создания каталога в файловой системе cgroup:
.P
.in +4n
.EX
mkdir /sys/fs/cgroup/cpu/cg1
.EE
.in
.P
Данная команда создаёт новую пустую cgroup.
.P
Помещение процесса в эту cgroup выполняется с помощью записи его PID в файл
cgroup \fIcgroup.procs\fP:
.P
.in +4n
.EX
echo $$ > /sys/fs/cgroup/cpu/cg1/cgroup.procs
.EE
.in
.P
В этот файл единовременно должен записываться только один PID.
.P
Запись в файл \fIcgroup.procs\fP значения 0 приводит к помещению в
соответствующую cgroup записывающего процесса.
.P
При записи PID в \fIcgroup.procs\fP в новую cgroup одновременно перемещаются
все нити процесса.
.P
Внутри иерархии процесс может быть членом только одной cgroup. Запись PID
процесса в файл \fIcgroup.procs\fP автоматически удаляет его из cgroup, в
которой он числился до этого.
.P
Для получения списка процессов, числящихся в cgroup, можно прочитать файл
\fIcgroup.procs\fP. Возвращаемый список PID не обязательно упорядочен. Также
PID могут повторяться (например, во время чтения списка PID может
использоваться повторно).
.P
.\"
В cgroups v1 отдельные нити могут перемещаться в другую cgroup посредством
записи ID нити (т. е., ядерный ID нити, возвращаемый \fBclone\fP(2) и
\fBgettid\fP(2)) в файл \fItasks\fP из каталога cgroup. Этот файл можно прочитать,
чтобы получить набор нитей, принадлежащих cgroup.
.SS "Удаление cgroups"
.\"
Удаляемая cgroup не должна содержать дочерних cgroups и процессов (не
зомби). Если это соблюдается, то можно просто удалить соответствующий
каталог. Заметим, что файлы в каталоге cgroup невозможно и ненужно удалять.
.SS "Выпуск уведомлений cgroups v1"
Для определения того, как ядро выполняет уведомления об опустевших cgroup,
можно использовать два файла. Cgroup считается пустой, если не содержит
дочерних cgroup и процессов.
.P
Специальный файл в корневом каталоге каждой иерархии cgroup,
\fIrelease_agent\fP, можно использовать для регистрации программы, которая
будет вызываться всякий раз, когда cgroup в иерархии становится пустой. При
вызове программы \fIrelease_agent\fP в единственной аргументе командной строки
передаётся путь (относительно точки монтирования cgroup) только что
опустевшей cgroup. Программа \fIrelease_agent\fP может удалить удалить каталог
cgroup или, возможно, повторно добавить в него процесс.
.P
По умолчанию файл \fIrelease_agent\fP пуст, то есть агент освобождения не
вызывается.
.P
Содержимое файла \fIrelease_agent\fP также можно задать в параметре
монтирования при монтировании файловой системы cgroup:
.P
.in +4n
.EX
mount \-o release_agent=файл …
.EE
.in
.P
.\"
Будет ли программа \fIrelease_agent\fP вызываться для определённой ставшей
пустой cgroup, задаётся значением файла \fInotify_on_release\fP в каталоге,
соответствующем cgroup. Если этот файл содержит значение  0, то программа
\fIrelease_agent\fP не вызывается. Если он содержит 1, то программа
\fIrelease_agent\fP вызывается. По умолчанию в этом файле содержится 0 для
корневой cgroup. В момент, когда создаётся новая cgroup, значение в этом
файле наследуется из соответствующего файла родительской cgroup.
.SS "Именованные иерархии cgroup v1"
В cgroups v1 возможно монтирование иерархии cgroup, у которой нет
присоединённых контроллеров:
.P
.in +4n
.EX
mount \-t cgroup \-o none,name=какое\-то_имя none /some/mount/point
.EE
.in
.P
Можно смонтировать несколько экземпляров таких иерархий; каждая иерархия
должна иметь уникальное имя. Единственной целью таких иерархий является
слежение за процессами (смотрите описание о выдаче уведомлений ниже). В
пример можно привести иерархию cgroup \fIname=systemd\fP, которая используется
\fBsystemd\fP(1) для слежения за службами и пользовательскими сеансами.
.P
.\"
Начиная с Linux 5.0, параметром ядра \fIcgroup_no_v1\fP (описан ниже) можно
выключить иерархию cgroup v1 с определённым именем: \fIcgroup_no_v1=named\fP.
.SH "CGROUPS ВЕРСИИ 2"
В cgroup v2 все смонтированные контроллеры располагаются в единой
унифицированной иерархии. Хотя (различные) контроллеры могут одновременно
монтироваться в иерархиях v1 и v2, невозможно одновременное монтирование
одного контроллера в обеих иерархиях v1 и v2.
.P
Далее приведено краткое описание новых правил поведения cgroups v2, и в
некоторых случаях, расширено в последующих подразделах.
.IP \[bu] 3
Cgroups v2 предоставляет унифицированную иерархию всех смонтированных
контроллеров.
.IP \[bu]
«Внутренние» процессы запрещены. За исключением корневой группы cgroup,
процессы могут располагаться только в крайних узлах (группа cgroup, которая
не содержит дочерних групп cgroup). Подробности несколько более тонкие, чем
эти и описаны ниже.
.IP \[bu]
Требуется указывать активные cgroup\-ы через файлы \fIcgroup.controllers\fP и
\fIcgroup.subtree_control\fP.
.IP \[bu]
Удалён файл \fItasks\fP. Также удалён файл \fIcgroup.clone_children\fP,
использовавшийся контроллером \fIcpuset\fP.
.IP \[bu]
Улучшенный механизм уведомлений о пустых cgroup доступен через файл
\fIcgroup.events\fP.
.P
For more changes, see the \fIDocumentation/admin\-guide/cgroup\-v2.rst\fP file in
the kernel source (or \fIDocumentation/cgroup\-v2.txt\fP in Linux 4.17 and
earlier).
.
.P
.\"
Некоторые новые упомянутые выше функциональные возможности появились с
добавлением в Linux 4.14 «режима нитей» (смотрите далее).
.SS "Унифицированная иерархия cgroups v2"
В cgroups v1, способность монтировать различные контроллеры в разные
иерархии предназначалась для повышения гибкости при разработки
приложения. Однако на практике выяснилось, что гибкость не так полезна как
ожидалось, и во многих случаях добавляет сложности. Поэтому в cgroups v2,
все доступные контроллеры монтируются в одну иерархию. Доступные контроллеры
монтируются автоматически, то есть не нужно (но можно) указывать контроллеры
при монтировании файловой системы cgroup v2 с помощью команды вида:
.P
.in +4n
.EX
mount \-t cgroup2 none /mnt/cgroup2
.EE
.in
.P
Контроллер cgroup v2 доступен только, если он уже не смонтирован в иерархии
cgroup v1. Или, иначе говоря, невозможно использовать тот же контроллер
одновременно в иерархии v1 и унифицированной иерархии v2. Это означает, что
сначала может потребоваться размонтировать контроллер v1 (как описано выше),
чтобы он стал доступен в v2. Так как \fBsystemd\fP(1) по умолчанию интенсивно
использует некоторые контроллеры v1, в некоторых случаях проще загрузить
систему с отключёнными контроллерами v1. Для этого укажите параметр
\fIcgroup_no_v1=список\fP в командной строке загрузки ядра; в \fIсписке\fP через
запятую перечисляются имена отключаемых контроллеров или указывается слово
\fIall\fP для выключения всех контроллеров v1 (этот вариант корректно
отрабатывается \fBsystemd\fP(1) и она начинает работать без указанных
контроллеров).
.P
.\"
Заметим, что во многих современных системах \fBsystemd\fP(1) автоматически
монтирует файловую систему \fIcgroup2\fP в каталог \fI/sys/fs/cgroup/unified\fP
при запуске системы.
.SS "Cgroups v2 mount options"
The following options (\fImount\ \-o\fP)  can be specified when mounting the
group v2 filesystem:
.TP 
\fInsdelegate\fP (начиная с Linux 4.15)
Treat cgroup namespaces as delegation boundaries.  For details, see below.
.TP 
\fImemory_localevents\fP (since Linux 5.2)
.\" commit 9852ae3fe5293264f01c49f2571ef7688f7823ce
.\"
The \fImemory.events\fP should show statistics only for the cgroup itself, and
not for any descendant cgroups.  This was the behavior before Linux 5.2.
Starting in Linux 5.2, the default behavior is to include statistics for
descendant cgroups in \fImemory.events\fP, and this mount option can be used to
revert to the legacy behavior.  This option is system wide and can be set on
mount or modified through remount only from the initial mount namespace; it
is silently ignored in noninitial namespaces.
.SS "Контроллеры cgroups v2"
The following controllers, documented in the kernel source file
\fIDocumentation/admin\-guide/cgroup\-v2.rst\fP (or
\fIDocumentation/cgroup\-v2.txt\fP in Linux 4.17 and earlier), are supported in
cgroups version 2:
.TP 
\fIcpu\fP (начиная с Linux 4.15)
Приемник контроллеров  \fIcpu\fP и \fIcpuacct\fP версии 1.
.TP 
\fIcpuset\fP (since Linux 5.0)
This is the successor of the version 1 \fIcpuset\fP controller.
.TP 
\fIfreezer\fP (since Linux 5.2)
.\" commit 76f969e8948d82e78e1bc4beb6b9465908e74873
This is the successor of the version 1 \fIfreezer\fP controller.
.TP 
\fIhugetlb\fP (since Linux 5.6)
This is the successor of the version 1 \fIhugetlb\fP controller.
.TP 
\fIio\fP (начиная с Linux 4.5)
Приемник контроллера \fIblkio\fP версии 1.
.TP 
\fImemory\fP (начиная с Linux 4.5)
Приемник контроллера \fImemory\fP версии 1.
.TP 
\fIperf_event\fP (начиная с Linux 4.11)
Совпадает с контроллером \fIperf_event\fP версии 1.
.TP 
\fIpids\fP (начиная с Linux 4.5)
Совпадает с контроллером \fIpids\fP версии 1.
.TP 
\fIrdma\fP (начиная с Linux 4.11)
Совпадает с контроллером \fIrdma\fP версии 1.
.P
There is no direct equivalent of the \fInet_cls\fP and \fInet_prio\fP controllers
from cgroups version 1.  Instead, support has been added to \fBiptables\fP(8)
to allow eBPF filters that hook on cgroup v2 pathnames to make decisions
about network traffic on a per\-cgroup basis.
.P
.\"
The v2 \fIdevices\fP controller provides no interface files; instead, device
control is gated by attaching an eBPF (\fBBPF_CGROUP_DEVICE\fP)  program to a
v2 cgroup.
.SS "Управление поддеревом cgroups v2"
Каждая cgroup в иерархии v2 содержит следующие два файла:
.TP 
\fIcgroup.controllers\fP
Доступный только для чтения файл со списком контроллеров, \fIдоступных\fP в
этой cgroup. Содержимое этого файла совпадает с содержимым файла
\fIcgroup.subtree_control\fP в родительской cgroup.
.TP 
\fIcgroup.subtree_control\fP
Список контроллеров, \fIактивных\fP (\fIвключённых\fP) в cgroup. Набор
контроллеров в этом файле является поднабором \fIcgroup.controllers\fP этой
cgroup. Изменение набора активных контроллеров выполняется записью строк в
этот файл с именами контроллеров через пробел; перед именами указывается «+»
(включить контроллер) или «\-» (выключить контроллер), как в следующем
примере:
.IP
.in +4n
.EX
echo \[aq]+pids \-memory\[aq] > x/y/cgroup.subtree_control
.EE
.in
.IP
Попытка включить контроллер, который отсутствует в \fIcgroup.controllers\fP,
приводит к ошибке \fBENOENT\fP при записи в файл \fIcgroup.subtree_control\fP.
.P
Так как список контроллеров в \fIcgroup.subtree_control\fP является поднабором
из \fIcgroup.controllers\fP, то контроллер, отключённый в иерархии cgroup,
невозможно включить в поддереве ниже этой cgroup.
.P
.\"
Файл cgroup \fIcgroup.subtree_control\fP определяет набор контроллеров, которые
выполняются в \fIдочерних\fP cgroup. Когда контроллер (например \fIpids\fP), есть
в файле \fIcgroup.subtree_control\fP родительской cgroup, то соответствующие
файлы интерфейса контроллера (например \fIpids.max\fP) автоматически создаются
в дочерних cgroup и могут использоваться для влияния на управление ресурсами
в дочерних cgroup.
.SS "Cgroups v2 \[dq]no internal processes\[dq] rule"
Cgroups v2 вводит так называемое правило «нет внутренним процессам». Грубо
говоря, это правило означает, что за исключением корневой cgroup, процессы
могут располагаться только в краевых  узлах (cgroup, которая не содержит
дочерних cgroup). Это позволяет не  решать как делить ресурсы между
процессами, которые являются членами cgroup A и процессами в дочерних
cgroup\-ах A.
.P
Например, если существует cgroup \fI/cg1/cg2\fP, то процесс может располагаться
в \fI/cg1/cg2\fP, но не в \fI/cg1\fP. Это решает проблему с неясностью в cgroups
v1 в плане разделения ресурсов между процессами в \fI/cg1\fP и её дочерних
cgroup\-ах. Рекомендуемый подход в cgroups v2 — создать подкаталог \fIleaf\fP
для всех конечных cgroup, в котором будут содержаться только процессы и
отсутствовать дочерние cgroup\-ы. То есть процессы, которые раньше находились
в \fI/cg1\fP теперь должны помещаться в \fI/cg1/leaf\fP. Преимуществом этого
является явное указание родства между процессами в \fI/cg1/leaf\fP и в других
потомках \fI/cg1\fP.
.P
The "no internal processes" rule is in fact more subtle than stated above.
More precisely, the rule is that a (nonroot) cgroup can't both (1) have
member processes, and (2) distribute resources into child cgroups\[em]that
is, have a nonempty \fIcgroup.subtree_control\fP file.  Thus, it \fIis\fP possible
for a cgroup to have both member processes and child cgroups, but before
controllers can be enabled for that cgroup, the member processes must be
moved out of the cgroup (e.g., perhaps into the child cgroups).
.P
.\"
С добавлением в Linux 4.14 «режима нитей» (смотрите далее) для некоторых
случаев применение правила «не внутренних процессов» было ослаблено.
.SS "Файл cgroup.events в cgroups v2"
Each nonroot cgroup in the v2 hierarchy contains a read\-only file,
\fIcgroup.events\fP, whose contents are key\-value pairs (delimited by newline
characters, with the key and value separated by spaces)  providing state
information about the cgroup:
.P
.in +4n
.EX
$ \fBcat mygrp/cgroup.events\fP
populated 1
frozen 0
.EE
.in
.P
The following keys may appear in this file:
.TP 
\fIpopulated\fP
The value of this key is either 1, if this cgroup or any of its descendants
has member processes, or otherwise 0.
.TP 
\fIfrozen\fP (since Linux 5.2)
.\" commit 76f969e8948d82e78e1bc4beb6b9465908e7487
The value of this key is 1 if this cgroup is currently frozen, or 0 if it is
not.
.P
.\"
The \fIcgroup.events\fP file can be monitored, in order to receive notification
when the value of one of its keys changes.  Such monitoring can be done
using \fBinotify\fP(7), which notifies changes as \fBIN_MODIFY\fP events, or
\fBpoll\fP(2), which notifies changes by returning the \fBPOLLPRI\fP and
\fBPOLLERR\fP bits in the \fIrevents\fP field.
.SS "Cgroup v2 release notification"
Cgroups v2 provides a new mechanism for obtaining notification when a cgroup
becomes empty.  The cgroups v1 \fIrelease_agent\fP and \fInotify_on_release\fP
files are removed, and replaced by the \fIpopulated\fP key in the
\fIcgroup.events\fP file.  This key either has the value 0, meaning that the
cgroup (and its descendants)  contain no (nonzombie) member processes, or 1,
meaning that the cgroup (or one of its descendants)  contains member
processes.
.P
The cgroups v2 release\-notification mechanism offers the following
advantages over the cgroups v1 \fIrelease_agent\fP mechanism:
.IP \[bu] 3
It allows for cheaper notification, since a single process can monitor
multiple \fIcgroup.events\fP files (using the techniques described earlier).
By contrast, the cgroups v1 mechanism requires the expense of creating a
process for each notification.
.IP \[bu]
.\"
Notification for different cgroup subhierarchies can be delegated to
different processes.  By contrast, the cgroups v1 mechanism allows only one
release agent for an entire hierarchy.
.SS "Файл cgroup.stat в cgroups v2"
.\" commit ec39225cca42c05ac36853d11d28f877fde5c42e
Каждая cgroup в иерархии v2 содержит файл \fIcgroup.stat\fP, доступный только
для чтения (появился в Linux 4.14), который состоит из строк с парами
ключ\-значение. В этом файле появляются следующие ключи:
.TP 
\fInr_descendants\fP
Общее количество видимых (т. е., живых) cgroups — потомков этой cgroup.
.TP 
\fInr_dying_descendants\fP
Общее количество прекративших работу cgroups — потомков этой cgroup. cgroups
входит в состояния прекращения жизнедеятельности после удаления. Она
остаётся в таком состоянии на неопределённых срок (зависит от системной
нагрузки), хотя ресурсы освобождаются до уничтожения cgroup. Заметим, что
существование несколькими cgroups в состоянии прекращения жизнедеятельности
нормально и не указывает на проблему.
.IP
.\"
Процесс не может стать членом прекратившей работу cgroup, и такая cgroup не
может опять заработать.
.SS "Ограничение на количество дочерних cgroups"
Каждая cgroup в иерархии v2 содержит следующие файлы, которые можно
использовать для просмотра и изменения количества дочерних cgroup в cgroup:
.TP 
\fIcgroup.max.depth\fP (начиная с Linux 4.14)
.\" commit 1a926e0bbab83bae8207d05a533173425e0496d1
Этим файлом задаётся ограничение глубины вложенности дочерних
cgroup. Значение 0 означает запрет на создание дочерних cgroup. Попытка
создать потомка, чья глубина вложенности превышает ограничение, завершается
ошибкой (\fImkdir\fP(2) завершается ошибкой \fBEAGAIN\fP).
.IP
Writing the string \fI\[dq]max\[dq]\fP to this file means that no limit is
imposed.  The default value in this file is \fI\[dq]max\[dq]\fP.
.TP 
\fIcgroup.max.descendants\fP (начиная с Linux 4.14)
.\" commit 1a926e0bbab83bae8207d05a533173425e0496d1
Этим файлом задаётся ограничение на количество действующих дочерних cgroup,
которое может иметь cgroup. Попытка создать больше потомков, чем разрешено,
приводит к ошибке (\fImkdir\fP(2) завершается ошибкой \fBEAGAIN\fP).
.IP
.\"
Writing the string \fI\[dq]max\[dq]\fP to this file means that no limit is
imposed.  The default value in this file is \fI\[dq]max\[dq]\fP.
.SH "ДЕЛЕГИРОВАНИЕ CGROUPS: ДЕЛЕГИРОВАНИЕ ИЕРАРХИИ МЕНЕЕ ПРИВИЛЕГИРОВАННОМУ ПОЛЬЗОВАТЕЛЮ"
В контексте cgroups, делегирование означает передачу управления частью
поддерева иерархии cgroup непривилегированному пользователю. Cgroups v1
предоставляют поддержку делегирования на основе файловых прав доступа в
иерархии cgroup, но эти правила менее ограничительны по сравнению с v2
(смотрите далее). Поддержка делегирования в cgroups v2 планировалась
изначально. В основном, этот раздел описывает делегирование для cgroups v2,
попутно указывая различия с cgroups v1.
.P
Для описания делегирования необходима некоторая
терминология. \fIДелегирующий\fP это привилегированный пользователь (т.е.,
корневой объект), которому принадлежит родительская группа
cgroup. \fIДелегат\fP это непривилегированный пользователь, которому будут
предоставлены права, необходимые для управления некоторой субиерархией в
родительской группе cgroup, также называемой \fIделегированным поддеревом\fP.
.P
Для делегирования, делегирующий создает определённые каталоги и файлы,
доступные на запись делегату, обычно, назначая владельцем объектов
идентификатором пользователя\-делегата. Предполагая, что нужно делегировать
иерархию с корнем (например) \fI/dlgt_grp\fP и что пока нет каких\-либо дочерних
cgroups в cgroup, меняем владельца на идентификатор пользователя\-делегата у
следующего:
.TP 
\fI/dlgt_grp\fP
Смена владельца корня поддерева означает, что любые новые cgroups, созданные
в поддереве (и файлы, которые они содержат), также будут принадлежать
делегату.
.TP 
\fI/dlgt_grp/cgroup.procs\fP
Смена владельца этого файла означает, что делегат может перемещать процессы
в корень делегированного ему поддерева.
.TP 
\fI/dlgt_grp/cgroup.subtree_control\fP (только cgroups v2)
Смена владельца этого файла означает, что делегат сможет включать
контроллеры (которые имеются в \fI/dlgt_grp/cgroup.controllers\fP), чтобы в
дальнейшем распределять ресурсы на более низких уровнях поддерева (вместо
изменения прав владения данным файлом делегирующий может добавить нужные
контроллеры в этот файл).
.TP 
\fI/dlgt_grp/cgroup.threads\fP (только cgroups v2)
Смена владельца этого файла требуется для делегирования поддерева с нитями
(смотрите описание «режима нитей» далее). Это позволяет делегату записывать
в файл ID нитей (также может быть изменён владелец файла для делегирования
поддерева домена, но пока это ни к чему не приводит, так как, судя по
описанному далее, невозможно перемещать нить между cgroup домена просто
записывая ID нити в файл \fIcgroup.threads\fP).
.IP
В cgroups v1 соответствующим файлом вместо делегируемого должен быть файл
\fItasks\fP.
.P
Делегирующий \fIне\fP должен изменять владельцев  файлов интерфейса контроллера
(например, \fIpids.max\fP, \fImemory.high\fP) в \fIdlgt_grp\fP. Эти файлы
используются со следующего уровня над делегируемым поддеревом, чтобы
распределить ресурсы в поддерево, и делегат не должен иметь права изменять
ресурсы, распределённые в делегируемое поддерево.
.P
Информацию о других делегируемых файлах cgroups v2 смотрите описание файла
\fI/sys/kernel/cgroup/delegate\fP в ЗАМЕЧАНИЯХ.
.P
.\"
После выполнения вышеуказанных шагов делегат может создавать подгруппы
cgroups в рамках делегированного поддерева (подкаталоги cgroup и файлы в них
будут принадлежать делегату) и перемещать процессы между группами cgroup в
поддереве. Если в \fIdlgt_grp/cgroup.subtree_control\fP есть контроллеры, или
право владения этим файлом перешло к делегату, то делегат также может
управлять дальнейшим распределением соответствующих ресурсов в
делегированном ему поддереве.
.SS "Делегирование cgroups v2: nsdelegate и пространство имён cgroup"
.\" commit 5136f6365ce3eace5a926e10f16ed2a233db5ba9
Начиная с Linux 4.13 появился второй способ делегирования cgroup в иерархии
cgroups v2. Этого можно достичь монтированием или перемонтированием файловой
системы cgroup v2 с параметром монтирования \fInsdelegate\fP. Например, если
файловая система cgroup v2 уже смонтирована, то её можно перемонтировать с
параметром \fInsdelegate\fP следующим образом:
.P
.in +4n
.EX
mount \-t cgroup2 \-o remount,nsdelegate \e
                 none /sys/fs/cgroup/unified
.EE
.in
.\"
.\" Alternatively, we could boot the kernel with the options:
.\"
.\"    cgroup_no_v1=all systemd.legacy_systemd_cgroup_controller
.\"
.\" The effect of the latter option is to prevent systemd from employing
.\" its "hybrid" cgroup mode, where it tries to make use of cgroups v2.
.P
Данный параметр монтирования заставляет пространства имён cgroup
автоматически устанавливать границы делегирования. При этом на процессы
внутри пространства имён cgroup накладываются следующие ограничения:
.IP \[bu] 3
Запись в файлы интерфейса к контроллерам в корневом каталоге пространства
имён завершаются ошибкой \fBEPERM\fP. Процессы внутри пространства имён cgroup
по\-прежнему могут писать в делегированные файлы корневого каталога
пространства имён cgroup (такие как \fIcgroup.procs\fP и
\fIcgroup.subtree_control\fP) и могут создавать новые иерархии в корневом
каталоге.
.IP \[bu]
Попытки переноса процессов за границу пространства имён пресекаются (с
ошибкой \fBENOENT\fP). Процессы внутри пространства имён cgroup по\-прежнему
могут (цель сдерживающих правил описана ниже) перемещать процессы между
cgroup \fIвнутри\fP иерархий корневого каталога.
.P
Возможность определения пространств имён cgroup для границ делегирования
делает пространства имён cgroup ещё более полезными. Чтобы понять почему,
предположим, что у нас уже есть одна иерархия cgroup, которая была
делегирована непривилегированному пользователю, \fIcecilia\fP, посредством
старого способа делегирования, описанного выше. Также предположим, что
\fIcecilia\fP тоже хочет делегировать одну иерархий из имеющихся в
делегированной иерархии (например, делегированная иерархия может быть
связана с непривилегированным контейнером, запущенным \fIcecilia\fP). Даже,
если пространство имён cgroup namespace было передано, так как обе иерархии
принадлежат непривилегированному пользователю \fIcecilia\fP, могут быть
выполнены следующие неправомерные действия:
.IP \[bu] 3
Процесс в нижележащей иерархии может изменять настройки контроллера ресурсов
в корневом каталоге этой иерархии (предполагается, что данными настройками
контроллера ресурсов управляют из \fIродительской\fP cgroup; процесс внутри
дочерней cgroup не должен быть способен изменять их).
.IP \[bu]
Процесс в нижележащей иерархии может перемещать процессы в и из нижележащей
иерархии, если cgroup вышестоящей иерархии видима откуда\-то ещё.
.P
Использование параметра монтирования \fInsdelegate\fP предотвращает обе эти
возможности.
.P
Параметр монтирования \fInsdelegate\fP действует только, когда применяется к
начальному пространству имён монтирования; для других пространств имён
монтирования он игнорируется.
.P
\fIЗамечание\fP: в некоторых системах \fBsystemd\fP(1) автоматически монтирует
файловую систему cgroup v2. Чтобы попробовать работу с \fInsdelegate\fP , может
быть полезно загрузить ядро с следующими параметрами командной строки:
.P
.in +4n
.EX
cgroup_no_v1=all systemd.legacy_systemd_cgroup_controller
.EE
.in
.P
.\"
Эти параметры заставляют ядро загружаться с выключенными контроллерами
cgroups v1 (т. е., контроллеры доступны из иерархии v2) и указывают
\fBsystemd\fP(1) не монтировать и использовать иерархию cgroup v2, таким
образом позволяя вручную смонтировать иерархию v2 с желаемыми параметрами
после загрузки.
.SS "Сдерживающие правила делегирования cgroup"
Некоторые \fIсдерживающие правила\fP делегирования обеспечивает то, что делегат
может перемещать процессы в рамках делегированного поддерева, но не сможет
перемещать процессы извне делегированного поддерева в поддерево и
наоборот. Непривилегированный процесс (т. е., делегат) может записать PID
«целевого» процесса в файл \fIcgroup.procs\fP только, если всё следующее верно:
.IP \[bu] 3
Писатель имеет права на запись в файл \fIcgroup.procs\fP в группе назначения
cgroup.
.IP \[bu]
Писатель имеет права на запись в файл \fIcgroup.procs\fP в ближайшем общем
предке для cgroups источника и назначения. Заметим, что в некоторых случаях,
ближайшим общим предком может быть сама cgroup источника или назначения. Это
требование не выполняется в иерархиях cgroups v1, в следствие чего
сдерживание в v1 менее ограничительно, чем v2 (например, в cgroups v1
пользователь, которому принадлежат две разных делегированных подиерархий,
может перемещать процесс между этими иерархиями).
.IP \[bu]
Если файловая система cgroup v2 смонтирована с параметром \fInsdelegate\fP, то
писатель способен видеть cgroup источника и приёмника из своего пространства
имён cgroup.
.IP \[bu]
.\" commit 576dd464505fc53d501bb94569db76f220104d28
В cgroups v1: эффективный UID писателя (т. е., делегата) совпадает с
реальным пользовательским ID или сохранённым set\-user\-ID процесса
назначения. До Linux 4.11 это требование также применялось к cgroups v2 (это
исторически сложившиеся требование, унаследовано от cgroups v1, которое
позднее сочли ненужным, так как достаточно других сдерживающих правил
cgroups v2).
.P
.\"
\fIЗамечание\fP: одним из следствий этих сдерживающих правил является то, что
непривилегированный делегат не может поместить первый процесс в
делегированное поддерево; вместо этого делегирующему необходимо поместить
первый процесс (процесс, принадлежащей делегату) в делегированное поддерево.
.SH "РЕЖИМ НИТЕЙ CGROUPS ВЕРСИИ 2"
Ограничения, налагаемые cgroups v2, но отсутствующие в cgroups v1:
.IP \[bu] 3
\fIНет понитевого управления\fP: все нити процесса должны быть в одной cgroup.
.IP \[bu]
\fIНет внутренних процессов\fP: cgroup не может иметь одновременно
процессов\-членов и выполняемых контроллеров в дочерних cgroup.
.P
Эти ограничения добавлены из\-за того, что их отсутствие вызывало проблемы в
cgroups v1. В частности, возможность понитевого контроля членства в cgroups
v1 приводило к бессмысленности некоторых контроллеров (особенно это касалось
контроллера \fImemory\fP: так как нити используют одно адресное пространство,
нет смысла разделять нити по разным \fImemory\fP cgroup).
.P
В первоначальном решении проекта cgroups v2 не учитывалось, что для
некоторых контроллеров, таких как \fIcpu\fP, было бы важным и полезным
задействовать понитевое управление. Чтобы приспособиться под такие случаи, в
Linux 4.14 для cgroups v2 добавлен \fIрежим нитей\fP.
.P
Режим нитей позволяет следующее:
.IP \[bu] 3
Создание \fIподдеревьев нитей\fP, в которых нити процесса могут размещаться по
нескольким cgroup внутри дерева (поддерево нитей может содержать несколько
многонитевых процессов).
.IP \[bu]
Концепцию \fIконтроллеров нитей\fP, которые могут распределять ресурсы между
cgroup в поддереве нитей.
.IP \[bu]
Ослабление «правила отсутствия внутренних процессов», то есть внутри
поддерева нитей cgroup может одновременно содержать нити и контроль ресурсов
над дочерними cgroup.
.P
Также, в режиме нитей каждая не корневая cgroup теперь содержит новый файл,
\fIcgroup.type\fP, который отражает и, в некоторых случаях, может
использоваться для изменения «типа» cgroup. Этот файл содержит одно из
следующих значений типа:
.TP 
\fIdomain\fP
Обычная cgroup v2, предоставляющая попроцессное управление. Если процесс
является членом этой cgroup, то все нити процесса (по определению) находятся
в одной cgroup. Это тип cgroup по умолчанию, предоставляет такое же
поведение, обеспечиваемое для cgroup начальной реализацией cgroups v2.
.TP 
\fIthreaded\fP
Данная cgroup является членом поддерева нитей. В эту cgroup нити могут
добавляться, а контроллеры cgroup включаться.
.TP 
\fIdomain threaded\fP
Доменная cgroup, которая служит корнем поддерева нитей. Этот тип cgroup
также называется «корнем нитей».
.TP 
\fIdomain invalid\fP
This is a cgroup inside a threaded subtree that is in an "invalid" state.
Processes can't be added to the cgroup, and controllers can't be enabled for
the cgroup.  The only thing that can be done with this cgroup (other than
deleting it)  is to convert it to a \fIthreaded\fP cgroup by writing the string
\fI\[dq]threaded\[dq]\fP to the \fIcgroup.type\fP file.
.IP
.\"
Обоснованием сущестования этого «переходного» типа при создании поддерева
нитей (вместо того, чтобы ядро сразу преобразовывало все cgroup в корне
нитей в тип \fIthreaded\fP) является задел для возможных будущих расширений
модели режима нитей.
.SS "Сравнение контроллеров домена и нитей"
С добавлением режима нитей теперь в cgroups v2 различают два типа
контроллеров ресурсов:
.IP \[bu] 3
.\" In the kernel source, look for ".threaded[ \t]*= true" in
.\" initializations of struct cgroup_subsys
Контроллеры \fIнитей\fP: эти контроллеры поддерживают понитевое управление
ресурсами и могут включаться в поддеревья нитей; в результате появляются
соответствующие файлы интерфейса контроллера внутри cgroup в поддереве
нитей. В Linux 4.19 имеются следующие контроллеры нитей: \fIcpu\fP,
\fIperf_event\fP и \fIpids\fP.
.IP \[bu]
.\"
Контроллеры \fIдомена\fP: эти контроллеры поддерживают только попроцессное
управление ресурсами. С точки зрения контроллера домена все нити процесса
всегда находятся в одной группе. Контроллеры домена нельзя включить внутри
поддерева нитей.
.SS "Создание поддерева нитей"
Существует два способа создания поддерева нитей. Первый:
.IP (1) 5
We write the string \fI\[dq]threaded\[dq]\fP to the \fIcgroup.type\fP file of a
cgroup \fIy/z\fP that currently has the type \fIdomain\fP.  This has the following
effects:
.RS
.IP \[bu] 3
Типом cgroup \fIy/z\fP становится \fIthreaded\fP.
.IP \[bu]
Типом родительской cgroup, \fIy\fP, становится \fIdomain threaded\fP. Родительская
cgroup является корнем поддерева нитей (также называемая «корнем нитей»).
.IP \[bu]
Все остальные cgroup в \fIy\fP, которые ещё не относятся к типу \fIthreaded\fP
преобразуются в тип \fIdomain invalid\fP (так как они внутри уже существующих
поддеревьев нитей с новом корне нитей). Все в дальнейшем создаваемые cgroup
в \fIy\fP также будут иметь тип \fIdomain invalid\fP.
.RE
.IP (2)
We write the string \fI\[dq]threaded\[dq]\fP to each of the \fIdomain invalid\fP
cgroups under \fIy\fP, in order to convert them to the type \fIthreaded\fP.  As a
consequence of this step, all threads under the threaded root now have the
type \fIthreaded\fP and the threaded subtree is now fully usable.  The
requirement to write \fI\[dq]threaded\[dq]\fP to each of these cgroups is
somewhat cumbersome, but allows for possible future extensions to the
thread\-mode model.
.P
Второй способ создания поддерева нитей:
.IP (1) 5
In an existing cgroup, \fIz\fP, that currently has the type \fIdomain\fP, we (1.1)
enable one or more threaded controllers and (1.2) make a process a member of
\fIz\fP.  (These two steps can be done in either order.)  This has the
following consequences:
.RS
.IP \[bu] 3
Типом \fIz\fP становится \fIdomain threaded\fP.
.IP \[bu]
All of the descendant cgroups of \fIz\fP that were not already of type
\fIthreaded\fP are converted to type \fIdomain invalid\fP.
.RE
.IP (2)
As before, we make the threaded subtree usable by writing the string
\fI\[dq]threaded\[dq]\fP to each of the \fIdomain invalid\fP cgroups under \fIz\fP,
in order to convert them to the type \fIthreaded\fP.
.P
.\"
Следствием одного из этих путей создания поддерева нитей является то, что
cgroup корня нитей может быть родителем только cgroup с типом \fIthreaded\fP (и
\fIdomain invalid\fP). cgroup корня нитей не может быть родителем cgroup с
типом \fIdomain\fP и cgroup с типом \fIthreaded\fP не может быть на одном уровне с
cgroup с типом \fIdomain\fP.
.SS "Использование поддерева нитей"
В поддереве нитей можно включать контроллеры нитей для каждой подгруппы, чей
тип был изменён на \fIthreaded\fP; после того, как это сделано, файлы
интерфейса соответствующего контроллера появятся в дочерних cgroup.
.P
Процесс можно перемещать в поддерево нитей посредством записи его PID в файл
\fIcgroup.procs\fP одной из cgroup внутри дерева. В результате все нити
процесса становятся членами соответствующей cgroup,а процесс — членом
поддерева нитей. После этого нити процесса можно размещать по поддереву
нитей посредством записи ID нитей (смотрите \fBgettid\fP(2)) в файлы
\fIcgroup.threads\fP различных cgroup внутри поддерева. Все нити процесса
должны быть расположены в одном поддереве нитей.
.P
Как и при записи в \fIcgroup.procs\fP, при записи в файл \fIcgroup.threads\fP
накладываются некоторые сдерживающие правила:
.IP \[bu] 3
Писатель должен иметь права на запись в файл cgroup.threads целевой cgroup.
.IP \[bu]
Писатель должен иметь права на запись в файл \fIcgroup.procs\fP в общем предке
для cgroups источника и назначения (в некоторых случаях, общим предком может
быть сама cgroup источника или назначения).
.IP \[bu]
Целевая и cgroup назначения должны быть в одном поддереве нитей (попытка
переместить нить вне поддерева нитей посредством записи ID этой нити в файл
\fIcgroup.threads\fP другой cgroup с типом \fIdomain\fP завершится ошибкой
\fBEOPNOTSUPP\fP).
.P
Файл \fIcgroup.threads\fP существует в каждой cgroup (включая cgroup c типом
\fIdomain\fP) и может быть прочитан для нахождения набора нитей, представленных
в группе. Для набора ID нитей, получаемых при чтении этого файла, не
гарантируется порядок и отсутствие повторов.
.P
Файл \fIcgroup.procs\fP в корне нитей отражает PID всех процессов, являющихся
членами поддерева нитей. Файлы \fIcgroup.procs\fP других cgroup в поддереве
недоступны для чтения.
.P
Доменные контроллеры невозможно включить в поддереве нитей; в cgroup ниже
корня нитей отсутствуют интерфейсные файлы контроллера. С точки зрения
доменного контроллера поддеревья нитей невидимы: многонитевые процессы
внутри поддерева нитей видятся доменным контроллером как процесс,
расположенный в cgroup корня нитей.
.P
.\"
В поддереве нитей правило «нет внутренних процессов» не применяется: cgroup
может иметь одновременно процессы\-члены (или нить) и выполняемые контроллеры
в дочерних cgroup.
.SS "Правила записи в cgroup.type и создание поддеревьев нитей"
При записи в файл \fIcgroup.type\fP накладывается несколько правил:
.IP \[bu] 3
Only the string \fI\[dq]threaded\[dq]\fP may be written.  In other words, the
only explicit transition that is possible is to convert a \fIdomain\fP cgroup
to type \fIthreaded\fP.
.IP \[bu]
The effect of writing \fI\[dq]threaded\[dq]\fP depends on the current value in
\fIcgroup.type\fP, as follows:
.RS
.IP \[bu] 3
\fIdomain\fP или \fIdomain threaded\fP: начинается создание поддерева нитей
(корнем будет родитель этой cgroup) посредством первого способа, описанного
выше;
.IP \[bu]
\fIdomain\ invalid\fP: эта cgroup (находящаяся внутри поддерева нитей)
переводится в работоспособное состояние (т. е., \fIthreaded\fP);
.IP \[bu]
\fIthreaded\fP: ничего не происходит («нет действия»).
.RE
.IP \[bu]
Нельзя писать в файл \fIcgroup.type\fP, если тип родителя \fIdomain invalid\fP. Иначе говоря, все cgroup поддерева нитей должны быть преобразованы
в состояние \fIthreaded\fP по нисходящей.
.P
Также для создания поддерева нитей с корнем cgroup \fIx\fP требуется выполнить
несколько условий:
.IP \[bu] 3
Не должно быть процессов\-членов в дочерних cgroup \fIx\fP (сама cgroup \fIx\fP
может иметь процессы\-члены).
.IP \[bu]
Не должно быть включённых доменных контроллеров для \fIx\fP в файле
\fIcgroup.subtree_control\fP.
.P
.\"
If any of the above constraints is violated, then an attempt to write
\fI\[dq]threaded\[dq]\fP to a \fIcgroup.type\fP file fails with the error
\fBENOTSUP\fP.
.SS "The \[dq]domain threaded\[dq] cgroup type"
Согласно способам, описанным выше, тип cgroup можно измениться на \fIdomain threaded\fP в следующих случаях:
.IP \[bu] 3
The string \fI\[dq]threaded\[dq]\fP is written to a child cgroup.
.IP \[bu]
Внутри cgroup включён контроллер нитей и процесс стал членом cgroup.
.P
A \fIdomain threaded\fP cgroup, \fIx\fP, can revert to the type \fIdomain\fP if the
above conditions no longer hold true\[em]that is, if all \fIthreaded\fP child
cgroups of \fIx\fP are removed and either \fIx\fP no longer has threaded
controllers enabled or no longer has member processes.
.P
Когда cgroup \fIx\fP с типом \fIdomain threaded\fP возвращается к типу \fIdomain\fP:
.IP \[bu] 3
Все потомки \fIx\fP с \fIdomain  invalid\fP, находящиеся не ниже уровня
поддеревьев нитей, получают тип \fIdomain\fP.
.IP \[bu]
.\"
Корневым cgroup, находящимся ниже поддеревьев нитей возвращается тип
\fIdomain threaded\fP.
.SS "Исключения для корневой cgroup"
The root cgroup of the v2 hierarchy is treated exceptionally: it can be the
parent of both \fIdomain\fP and \fIthreaded\fP cgroups.  If the string
\fI\[dq]threaded\[dq]\fP is written to the \fIcgroup.type\fP file of one of the
children of the root cgroup, then
.IP \[bu] 3
Типом этой cgroup становится \fIthreaded\fP.
.IP \[bu]
Тип всех потомков этой cgroup, не являющихся частью уровня ниже поддеревьев
нитей, изменяется на \fIdomain invalid\fP.
.P
Заметим, что в этом случае нет cgroup, чей тип стал \fIdomain threaded\fP (в
принципе, корневая cgroup может рассматриваться как корень нитей для cgroup,
чей тип был изменён на \fIthreaded\fP).
.P
.\"
Данное исключение для корневой cgroup позволяет cgroup нитей, запускающей
контроллер \fIcpu\fP, быть помещённой выше всех насколько возможно в иерархии,
для того, чтобы минимизировать ущерб (маленький) от обхода иерархии cgroup.
.SS "The cgroups v2 \[dq]cpu\[dq] controller and realtime threads"
As at Linux 4.19, the cgroups v2 \fIcpu\fP controller does not support control
of realtime threads (specifically threads scheduled under any of the
policies \fBSCHED_FIFO\fP, \fBSCHED_RR\fP, described \fBSCHED_DEADLINE\fP; see
\fBsched\fP(7)).  Therefore, the \fIcpu\fP controller can be enabled in the root
cgroup only if all realtime threads are in the root cgroup.  (If there are
realtime threads in nonroot cgroups, then a \fBwrite\fP(2)  of the string
\fI\[dq]+cpu\[dq]\fP to the \fIcgroup.subtree_control\fP file fails with the error
\fBEINVAL\fP.)
.P
.\"
В некоторых системах \fBsystemd\fP(1) помещает определённые нити реального
времени в некорневую cgroups иерархии v2. В таких системах такие нити должны
помещаться раньше в корневую cgroup, до включения контроллера \fIcpu\fP.
.SH ОШИБКИ
Следующие ошибки могут возникать при \fBmount\fP(2):
.TP 
\fBEBUSY\fP
При монтировании файловой системы cgroup версии 1 не указан параметр
\fIname=\fP (для монтирования именованной иерархии) или имя контроллера (или
\fIall\fP).
.SH ПРИМЕЧАНИЯ
Дочерний процесс, созданный \fBfork\fP(2), наследует членство родителя в
cgroup. Членство в cgroup сохраняется при \fBexecve\fP(2).
.P
.\"
The \fBclone3\fP(2)  \fBCLONE_INTO_CGROUP\fP flag can be used to create a child
process that begins its life in a different version 2 cgroup from the parent
process.
.SS "Файлы в /proc"
.TP 
\fI/proc/cgroups\fP (начиная с Linux 2.6.24)
В этом файле содержится информация о контроллерах, с которыми было собрано
ядро. Пример содержимого файла (переформатирован для читабельности):
.IP
.in +4n
.EX
#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
.EE
.in
.IP
Поля файла, слева направо:
.RS
.IP [1] 5
Имя контроллера.
.IP [2]
Уникальный ID иерархии cgroup, на которой смонтирован контроллер. Если к
одной иерархии привязано несколько контроллеров cgroups v1, то для каждого в
этом поле будет показан одинаковый ID иерархии. Значение поля равно 0, если:
.RS
.IP \[bu] 3
контроллер не смонтирован на иерархию cgroups v1;
.IP \[bu]
контроллер привязан к унифицированной иерархии cgroups v2; или
.IP \[bu]
контроллер отключён (смотрите ниже).
.RE
.IP [3]
Количество контролируемых групп в этой иерархии, использующих этот
контроллер.
.IP [4]
В этом поле содержится значение 1, если этот контроллер включён, или 0, если
он выключен (с помощью параметра \fIcgroup_disable\fP командной строки загрузки
ядра).
.RE
.TP 
\fI/proc/\fPpid\fI/cgroup\fP (начиная с Linux 2.6.24)
Этот файл описывает управляемые группы, которым принадлежит процесс с
соответствующим PID. Отображаемая информация отличается для иерархий cgroups
версии 1 и 2.
.IP
Для каждой иерархии cgroup, членом которой является процесс, существует одна
запись, состоящая из трёх полей через двоеточие:
.IP
.in +4n
.EX
ID иерархии:список контроллеров:путь cgroup
.EE
.in
.IP
Пример:
.IP
.in +4n
.EX
5:cpuacct,cpu,cpuset:/daemons
.EE
.in
.IP
Поля, разделяемые двоеточием, слева направо:
.RS
.IP [1] 5
Для иерархии cgroups версии 1 это поле содержит уникальный ID номер
иерархии, который может совпадать с ID иерархии в \fI/proc/cgroups\fP. Для
иерархии cgroups версии 2 это поле содержит значение 0.
.IP [2]
Для иерархии cgroups версии 1 это поле содержит список контроллеров,
привязанных к иерархии, перечисленных через запятую. Для иерархии cgroups
версии 2 это поле пусто.
.IP [3]
Это поле содержит путь управляемой группы в иерархии, которой принадлежит
процесс. Путь является относительным точки монтирования иерархии.
.RE
.\"
.SS "Файлы /sys/kernel/cgroup"
.TP 
\fI/sys/kernel/cgroup/delegate\fP (начиная с Linux 4.15)
.\" commit 01ee6cfb1483fe57c9cbd8e73817dfbf9bacffd3
Этот файл экспортирует список файлов cgroups v2 (один на строку), которые
можно делегировать (т. е., у которых можно изменить владельца на
пользовательских ID делегата). В будущем, наборов доступных для
делегирования файлов может измениться или вырасти, а этот файл предоставляет
способ, которым ядро информирует приложения пользовательского пространства о
необходимых для делегирования файлах. В Linux 4.15 в этом файле можно
увидеть следующее:
.IP
.in +4n
.EX
$ \fBcat /sys/kernel/cgroup/delegate\fP
cgroup.procs
cgroup.subtree_control
cgroup.threads
.EE
.in
.TP 
\fI/sys/kernel/cgroup/features\fP (начиная с Linux 4.15)
.\" commit 5f2e673405b742be64e7c3604ed4ed3ac14f35ce
Со временем набор возможностей cgroups v2, предоставляемых ядром, может
измениться или вырасти, или некоторые возможности по умолчанию могут быть
отключены. Этот файл предоставляет способ, которым приложения
пользовательского пространства могут узнать о том, какие возможности
поддерживает работающее ядро и какие из них включены. Возможности
перечисляются по одной на строку:
.IP
.in +4n
.EX
$ \fBcat /sys/kernel/cgroup/features\fP
nsdelegate
memory_localevents
.EE
.in
.IP
В этом файле может появляться следующее:
.RS
.TP 
\fImemory_localevents\fP (since Linux 5.2)
The kernel supports the \fImemory_localevents\fP mount option.
.TP 
\fInsdelegate\fP (начиная с Linux 4.15)
Поддержка параметра монтирования \fInsdelegate\fP ядром.
.TP 
\fImemory_recursiveprot\fP (since Linux 5.7)
.\" commit 8a931f801340c2be10552c7b5622d5f4852f3a36
The kernel supports the \fImemory_recursiveprot\fP mount option.
.RE
.SH "СМОТРИТЕ ТАКЖЕ"
\fBprlimit\fP(1), \fBsystemd\fP(1), \fBsystemd\-cgls\fP(1), \fBsystemd\-cgtop\fP(1),
\fBclone\fP(2), \fBioprio_set\fP(2), \fBperf_event_open\fP(2), \fBsetrlimit\fP(2),
\fBcgroup_namespaces\fP(7), \fBcpuset\fP(7), \fBnamespaces\fP(7), \fBsched\fP(7),
\fBuser_namespaces\fP(7)
.P
The kernel source file \fIDocumentation/admin\-guide/cgroup\-v2.rst\fP.
.PP
.SH ПЕРЕВОД
Русский перевод этой страницы руководства разработал
Azamat Hackimov <azamat.hackimov@gmail.com>,
Dmitriy S. Seregin <dseregin@59.ru>,
Dmitry Bolkhovskikh <d20052005@yandex.ru>,
Katrin Kutepova <blackkatelv@gmail.com>,
Yuri Kozlov <yuray@komyakino.ru>
и
Иван Павлов <pavia00@gmail.com>
.
.PP
Этот перевод является свободной программной документацией; он распространяется
на условиях общедоступной лицензии GNU (GNU General Public License - GPL,
.UR https://www.gnu.org/licenses/gpl-3.0.html
.UE
версии 3 или более поздней) в отношении
авторского права, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ.
.PP
Если вы обнаружите какие-либо ошибки в переводе этой страницы руководства, пожалуйста,
сообщите об этом разработчику по его адресу электронной почты или по адресу
.MT <debian-l10n-russian@lists.debian.org>
списка рассылки русских переводчиков
.ME .