SymbX/systemd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

core: add DelegateSubgroup= setting

Browse Source 
This implements a minimal subset of #24961, but in a lot more
restrictive way: we only allow one level of subcgroup (as that's enough
to address the no-processes in inner cgroups rule), and does not change
anything about threaded cgroup logic or similar, or make any of this new
behaviour mandatory.

All this does is this: all non-control processes we invoke for a unit
we'll invoke in a subgroup by the specified name.

We'll later port all our current services that use cgroup delegation
over to this, i.e. user@.service, systemd-nspawn@.service and
systemd-udevd.service.
This commit is contained in:
Lennart Poettering
2023-04-27 12:18:32 +02:00
parent 1a56b0c05d
commit a8b993dc11
11 changed files with 168 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
man/systemd.resource-control.xml
+28 -4
View File
@@ -1148,10 +1148,11 @@ DeviceAllow=/dev/loop-control
<term><varname>Delegate=</varname></term>
<listitem>
<para>Turns on delegation of further resource control partitioning to processes of the unit. Units where this
is enabled may create and manage their own private subhierarchy of control groups below the control group of
the unit itself. For unprivileged services (i.e. those using the <varname>User=</varname> setting) the unit's
control group will be made accessible to the relevant user.</para>
<para>Turns on delegation of further resource control partitioning to processes of the unit. Units
where this is enabled may create and manage their own private subhierarchy of control groups below
the control group of the unit itself. For unprivileged services (i.e. those using the
<varname>User=</varname> setting) the unit's control group will be made accessible to the relevant
user.</para>
<para>When enabled the service manager will refrain from manipulating control groups or moving
processes below the unit's control group, so that a clear concept of ownership is established: the
@@ -1188,6 +1189,29 @@ DeviceAllow=/dev/loop-control
</listitem>
</varlistentry>
<varlistentry>
<term><varname>DelegateSubgroup=</varname></term>
<listitem>
<para>Place unit processes in the specified subgroup of the unit's control group. Takes a valid
control group name (not a path!) as parameter, or an empty string to turn this feature
off. Defaults to off. The control group name must be usable as filename and avoid conflicts with
the kernel's control group attribute files (i.e. <filename>cgroup.procs</filename> is not an
acceptable name, since the kernel exposes a native control group attribute file by that name). This
option has no effect unless control group delegation is turned on via <varname>Delegate=</varname>,
see above. Note that this setting only applies to "main" processes of a unit, i.e. for services to
<varname>ExecStart=</varname>, but not for <varname>ExecReload=</varname> and similar. If
delegation is enabled, the latter are always placed inside a subgroup named
<filename>.control</filename>. The specified subgroup is automatically created (and potentially
ownership is passed to the unit's configured user/group) when a process is started in it.</para>
<para>This option is useful to avoid manually moving the invoked process into a subgroup after it
has been started. Since no processes should live in inner nodes of the control group tree it's
almost always necessary to run the main ("supervising") process of a unit that has delegation
turned on in a subgroup.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>DisableControllers=</varname></term>