<para>If <literal>replace-irreversibly</literal> is specified,
operate like <literal>replace</literal>, but also mark the new
jobs as irreversible. This prevents future conflicting
- transactions from replacing these jobs. The jobs can still be
- cancelled using the <command>cancel</command> command.</para>
+ transactions from replacing these jobs (or even being enqueued
+ while the irreversible jobs are still pending). Irreversible
+ jobs can still be cancelled using the <command>cancel</command>
+ command.</para>
<para><literal>isolate</literal> is only valid for start
operations and causes all other units to be stopped when the
<listitem>
<para>When used with <command>kill</command>, choose which
- processes to kill. Must be one of <option>main</option>,
- <option>control</option> or <option>all</option> to select
- whether to kill only the main process of the unit, the
- control process or all processes of the unit. If omitted,
- defaults to <option>all</option>.</para>
+ processes to send a signal to. Must be one of
+ <option>main</option>, <option>control</option> or
+ <option>all</option> to select whether to kill only the main
+ process, the control process or all processes of the
+ unit. The main process of the unit is the one that defines
+ the life-time of it. A control process of a unit is one that
+ is invoked by the manager to induce state changes of it. For
+ example, all processes started due to the
+ <varname>ExecStartPre=</varname>,
+ <varname>ExecStop=</varname> or
+ <varname>ExecReload=</varname> settings of service units are
+ control processes. Note that there is only one control
+ process per unit at a time, as only one state change is
+ executed at a time. For services of type
+ <varname>Type=forking</varname>, the initial process started
+ by the manager for <varname>ExecStart=</varname> is a
+ control process, while the process ultimately forked off by
+ that one is then considered the main process of the unit (if
+ it can be determined). This is different for service units
+ of other types, where the process forked off by the manager
+ for <varname>ExecStart=</varname> is always the main process
+ itself. A service unit consists of zero or one main process,
+ zero or one control process plus any number of additional
+ processes. Not all unit types manage processes of these
+ types however. For example, for mount units, control processes
+ are defined (which are the invocations of
+ <filename>/usr/bin/mount</filename> and
+ <filename>/usr/bin/umount</filename>), but no main process
+ is defined. If omitted, defaults to
+ <option>all</option>.</para>
</listitem>
</varlistentry>
safe option to request an immediate reboot. If
<option>--force</option> is specified twice for these
operations, they will be executed immediately without
- terminating any processes or umounting any file
+ terminating any processes or unmounting any file
systems. Warning: specifying <option>--force</option> twice
with any of these operations might result in data
loss.</para>
<para>Show terse runtime status information about one or
more units, followed by most recent log data from the
journal. If no units are specified, show system status. If
- combined with <option>--all</option> also shows status of
+ combined with <option>--all</option>, also show the status of
all units (subject to limitations specified with
<option>-t</option>). If a PID is passed, show information
about the unit the process belongs to.</para>
activation of the unit, including manual activation. Use
this option with care. This honors the
<option>--runtime</option> option to only mask temporarily
- until the next reoobt of the system.</para>
+ until the next reboot of the system.</para>
</listitem>
</varlistentry>
<refsect2>
<title>Parameter Syntax</title>
- <para>Unit ommands listed above take either a single unit name
+ <para>Unit commands listed above take either a single unit name
(designated as <replaceable>NAME</replaceable>), or multiple
unit specifications (designated as
<replaceable>PATTERN</replaceable>...). In the first case, the