<refsect1>
<title>Description</title>
- <para>Unit configuration files for services, sockets
+ <para>Unit configuration files for services, sockets,
mount points and swap devices share a subset of
configuration options which define the execution
environment of spawned processes.</para>
<para>This man page lists the configuration options
- shared by these three unit types. See
+ shared by these four unit types. See
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for the common options of all unit configuration
files, and
"-", which indicates that if the file
does not exist it won't be read and no
error or warning message is
- logged.</para></listitem>
+ logged. The files listed with this
+ directive will be read shortly before
+ the process is executed. Settings from
+ these files override settings made
+ with
+ <varname>Environment=</varname>. If
+ the same variable is set twice from
+ these files the files will be read in
+ the order they are specified and the
+ later setting will override the
+ earlier setting. </para></listitem>
</varlistentry>
<varlistentry>
<filename>/dev/console</filename>.</para></listitem>
</varlistentry>
<varlistentry>
- <term><varname>SyslogIdentifer=</varname></term>
+ <term><varname>TTYReset=</varname></term>
+ <listitem><para>Reset the terminal
+ device specified with
+ <varname>TTYPath=</varname> before and
+ after execution. Defaults to
+ <literal>no</literal>.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>TTYVHangup=</varname></term>
+ <listitem><para>Disconnect all clients
+ which have opened the terminal device
+ specified with
+ <varname>TTYPath=</varname>
+ before and after execution. Defaults
+ to
+ <literal>no</literal>.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>TTYVTDisallocate=</varname></term>
+ <listitem><para>If the the terminal
+ device specified with
+ <varname>TTYPath=</varname> is a
+ virtual console terminal try to
+ deallocate the TTY before and after
+ execution. This ensures that the
+ screen and scrollback buffer is
+ cleared. Defaults to
+ <literal>no</literal>.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>SyslogIdentifier=</varname></term>
<listitem><para>Sets the process name
to prefix log lines sent to syslog or
the kernel log buffer with. If not set
various resource limits for executed
processes. See
<citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
- for details.</para></listitem>
+ for details. Use the string
+ <varname>infinity</varname> to
+ configure no limit on a specific
+ resource.</para></listitem>
</varlistentry>
<varlistentry>
</varlistentry>
<varlistentry>
- <term><varname>Capabilities=</varname></term>
- <listitem><para>Controls the
+ <term><varname>ControlGroupModify=</varname></term>
+ <listitem><para>Takes a boolean
+ argument. If true, the control groups
+ created for this unit will be owned by
+ ther user specified with
+ <varname>User=</varname> (and the
+ configured group), and he can create
+ subgroups as well as add processes to
+ the group.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>CapabilityBoundingSet=</varname></term>
+
+ <listitem><para>Controls which
+ capabilities to include in the
+ capability bounding set for the
+ executed process. See
<citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- set for the executed process. Take a
- capability string as described in
- <citerefentry><refentrytitle>cap_from_text</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
- Note that this capability set is
- usually influenced by the capabilities
- attached to the executed
- file.</para></listitem>
+ for details. Takes a whitespace
+ separated list of capability names as
+ read by
+ <citerefentry><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+ Capabilities listed will be included
+ in the bounding set, all others are
+ removed. If the list of capabilities
+ is prefixed with ~ all but the listed
+ capabilities will be included, the
+ effect of the assignment
+ inverted. Note that this option does
+ not actually set or unset any
+ capabilities in the effective,
+ permitted or inherited capability
+ sets. That's what
+ <varname>Capabilities=</varname> is
+ for. If this option is not used the
+ capability bounding set is not
+ modified on process execution, hence
+ no limits on the capabilities of the
+ process are enforced.</para></listitem>
</varlistentry>
<varlistentry>
</varlistentry>
<varlistentry>
- <term><varname>CapabilityBoundingSetDrop=</varname></term>
-
+ <term><varname>Capabilities=</varname></term>
<listitem><para>Controls the
- capability bounding set drop set for
- the executed process. See
<citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- for details. Takes a list of
- capability names as read by
- <citerefentry><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
- </para></listitem>
+ set for the executed process. Take a
+ capability string describing the
+ effective, permitted and inherited
+ capability sets as documented in
+ <citerefentry><refentrytitle>cap_from_text</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+ Note that these capability sets are
+ usually influenced by the capabilities
+ attached to the executed file. Due to
+ that
+ <varname>CapabilityBoundingSet=</varname>
+ is probably the much more useful
+ setting.</para></listitem>
</varlistentry>
<varlistentry>
path for this unit is implied. This
option may be used to place executed
processes in arbitrary groups in
- arbitrary hierachies -- which can be
+ arbitrary hierarchies -- which can be
configured externally with additional execution limits. By default
systemd will place all executed
processes in separate per-unit control
usual file access controls would
permit this. Directories listed in
<varname>InaccessibleDirectories=</varname>
- will be made inaccesible for processes
+ will be made inaccessible for processes
inside the namespace. Note that
restricting access with these options
does not extend to submounts of a