+ 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="http://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="http://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>