man: drop the old cgroup settings from the man pages

This commit is contained in:
Lennart Poettering 2013-07-19 17:23:10 +02:00
parent e2f2fb7860
commit dc7adf202b
3 changed files with 12 additions and 165 deletions

11
TODO
View File

@ -21,13 +21,7 @@ Bugfixes:
Fedora 20:
* external: maybe it is time to patch procps so that "ps" links to
libsystemd-logind to print a pretty service name, seat name, session
name in its output. Currently it only shows cgroup membership, but
that's sometimes kinda hard to parse for a human.
* cgroup attrs:
- update dbus interface docs in wiki
* external: ps should gain colums for slice and machine
* localed:
- localectl: support new converted x11→console keymaps
@ -51,7 +45,8 @@ CGroup Rework Completion:
* introduce high-level settings for RT budget, swappiness
* wiki: document new bus APIs of PID 1
* wiki: document new bus APIs of PID 1 (transient units, Reloading signal), systemctl commands
* review: scope units, slice units, pid1, machinectl, libsystem-login, pam_systemd, systemd-run, systemd-nspawn
* Send SIGHUP and SIGTERM in session scopes

View File

@ -309,9 +309,14 @@ along with systemd; If not, see <http://www.gnu.org/licenses/>.
<listitem>
<para>The name of the slice unit to place the unit
in. Defaults to <filename>system.slice</filename> for all
unit types, except for slice units themselves. This may be
used to arrange systemd units in a hierarchy of slices each
of which might have resource settings applied.</para>
non-instantiated units of all unit types (except for slice
units themselves see below). Instance units are by default
placed in a subslice of <filename>system.slice</filename>
that is named after the template name.</para>
<para>This option may be used to arrange systemd units in a
hierarchy of slices each of which might have resource
settings applied.</para>
<para>For units of type slice the only accepted value for
this setting is the parent slice. Since the name of a slice

View File

@ -791,160 +791,6 @@
setting.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>ControlGroup=</varname></term>
<listitem><para>Controls the control
groups the executed processes shall be
made members of. Takes a
space-separated list of cgroup
identifiers. A cgroup identifier is
formatted like
<filename noindex='true'>cpu:/foo/bar</filename>,
where "cpu" indicates the kernel
control group controller used, and
<filename noindex='true'>/foo/bar</filename> is the
control group path. The controller
name and ":" may be omitted in which
case the named systemd control group
hierarchy is implied. Alternatively,
the path and ":" may be omitted, in
which case the default control group
path for this unit is implied.</para>
<para>This option may be used to place
executed processes in arbitrary groups
in arbitrary hierarchies -- which may
then be externally configured with
additional execution limits. By
default systemd will place all
executed processes in separate
per-unit control groups (named after
the unit) in the systemd named
hierarchy. This option is primarily
intended to place executed processes
in specific paths in specific kernel
controller hierarchies. It is not
recommended to manipulate the service
control group path in the private
systemd named hierarchy
(i.e. <literal>name=systemd</literal>),
and doing this might result in
undefined behaviour. For details about
control groups see <ulink
url="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>.</para>
<para>This option may appear more than
once, in which case the list of
control group assignments is
merged. If the same hierarchy gets two
different paths assigned only the
later setting will take effect. If the
empty string is assigned to this
option the list of control group
assignments is reset, all previous
assignments will have no
effect.</para>
<para>Note that the list of control
group assignments of a unit is
extended implicitly based on the
settings of
<varname>DefaultControllers=</varname>
of
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
but a unit's
<varname>ControlGroup=</varname>
setting for a specific controller
takes precedence.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>ControlGroupModify=</varname></term>
<listitem><para>Takes a boolean
argument. If true, the control groups
created for this unit will be owned by
the user specified with
<varname>User=</varname> (and the
appropriate group), and he/she can create
subgroups as well as add processes to
the group.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>ControlGroupPersistent=</varname></term>
<listitem><para>Takes a boolean
argument. If true, the control groups
created for this unit will be marked
to be persistent, i.e. systemd will
not remove them when stopping the
unit. The default is false, meaning
that the control groups will be
removed when the unit is stopped. For
details about the semantics of this
logic see <ulink
url="http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups">PaxControlGroups</ulink>.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>ControlGroupAttribute=</varname></term>
<listitem><para>Set a specific control
group attribute for executed
processes, and (if needed) add the
executed processes to a cgroup in the
hierarchy of the controller the
attribute belongs to. Takes two
space-separated arguments: the
attribute name (syntax is
<literal>cpu.shares</literal> where
<literal>cpu</literal> refers to a
specific controller and
<literal>shares</literal> to the
attribute name), and the attribute
value. Example:
<literal>ControlGroupAttribute=cpu.shares
512</literal>. If this option is used
for an attribute that belongs to a
kernel controller hierarchy the unit
is not already configured to be added
to (for example via the
<literal>ControlGroup=</literal>
option) then the unit will be added to
the controller and the default unit
cgroup path is implied. Thus, using
<varname>ControlGroupAttribute=</varname>
is in most cases sufficient to make
use of control group enforcements,
explicit
<varname>ControlGroup=</varname> are
only necessary in case the implied
default control group path for a
service is not desirable. For details
about control group attributes see
<ulink
url="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>. This
option may appear more than once, in
order to set multiple control group
attributes. If this option is used
multiple times for the same cgroup
attribute only the later setting takes
effect. If the empty string is
assigned to this option the list of
attributes is reset, all previous
cgroup attribute settings have no
effect, including those done with
<varname>CPUShares=</varname>,
<varname>MemoryLimit=</varname>,
<varname>MemorySoftLimit</varname>,
<varname>DeviceAllow=</varname>,
<varname>DeviceDeny=</varname>,
<varname>BlockIOWeight=</varname>,
<varname>BlockIOReadBandwidth=</varname>,
<varname>BlockIOWriteBandwidth=</varname>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>ReadWriteDirectories=</varname></term>
<term><varname>ReadOnlyDirectories=</varname></term>
@ -1143,6 +989,7 @@
<citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.cgroup</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
</para>
</refsect1>