<term><varname>luks</varname></term>
<listitem><para>Force LUKS mode. When this mode
- is used the following options are ignored since
+ is used, the following options are ignored since
they are provided by the LUKS header on the
device: <varname>cipher=</varname>,
<varname>hash=</varname>,
<term><varname>tcrypt</varname></term>
<listitem><para>Use TrueCrypt encryption mode.
- When this mode is used the following options are
+ When this mode is used, the following options are
ignored since they are provided by the TrueCrypt
header on the device or do not apply:
<varname>cipher=</varname>,
<option>short-iso</option>
</term>
<listitem>
- <para>is very similar
+ <para>is very similar,
but shows ISO 8601
wallclock timestamps.
</para>
<term><option>--signal=</option></term>
<listitem><para>When used with
- <command>kill-machine</command> choose
+ <command>kill-machine</command>, choose
which signal to send to selected
processes. Must be one of the
well-known signal specifiers, such as
<listitem><para>A new systemd scope unit is
created for the session. If this is the first
- concurrent session of the user an implicit
+ concurrent session of the user, an implicit
slice below <filename>user.slice</filename> is
automatically created and the scope placed in
it. In instance of the system service
- <filename>user@.service</filename> which runt
+ <filename>user@.service</filename> which runs
the systemd user manager
instance.</para></listitem>
</orderedlist>
<para>On logout, this module ensures the following:</para>
<orderedlist>
- <listitem><para>If this is enabled all
+ <listitem><para>If this is enabled, all
processes of the session are terminated. If
- the last concurrent session of a user ends his
+ the last concurrent session of a user ends, his
user systemd instance will be terminated too,
and so will the user's slice
unit.</para></listitem>
- <listitem><para>If the las concurrent session
- of a user ends the
+ <listitem><para>If the last concurrent session
+ of a user ends, the
<varname>$XDG_RUNTIME_DIR</varname> directory
and all its contents are removed,
too.</para></listitem>
<term><option>--state=</option></term>
<listitem>
- <para>Argument should be a comma-separated list of unit LOAD
- or SUB or ACTIVE states. When listing units show only those
+ <para>The argument should be a comma-separated list of unit LOAD
+ or SUB or ACTIVE states. When listing units, show only those
with specified LOAD or SUB or ACTIVE state.</para>
</listitem>
</varlistentry>
is lost on reboot, the changes are lost too.</para>
<para>Similar, when used with
- <command>set-property</command> make changes only
+ <command>set-property</command>, make changes only
temporarily, so that they are lost on the next
reboot.</para>
</listitem>
<citerefentry><refentrytitle>systemd.cgroup</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
may. The changes are applied instantly, and stored on disk
for future boots, unless <option>--runtime</option> is
- passed in which case the settings only apply until the next
+ passed, in which case the settings only apply until the next
reboot. The syntax of the property assignment follows
closely the syntax of assignments in unit files.</para>
<para>Note that this command allows changing multiple
properties at the same time, which is preferable over
setting them individually. Like unit file configuration
- settings assigning the empty list to list parameters will
+ settings, assigning the empty list to list parameters will
reset the list.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-o</option></term>
<term><option>--output <replaceable>path</replaceable></option></term>
- <listitem><para>Specify the output folder for the
+ <listitem><para>Specify the output directory for the
graphs. By default, bootchart writes the graphs to
<filename>/run/log</filename>.</para></listitem>
</varlistentry>
<para>See
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
- for some examples how to start a container the systemd
+ for some examples on how to start a container the systemd
way.</para>
<para>See the <ulink
<para>All command-line arguments after the first non-option
argument become part of the commandline of the launched
- process. If a command is run as service unit its first argument
+ process. If a command is run as service unit, its first argument
needs to be an absolute binary path.</para>
</refsect1>
hierarchy of slices each of which might have resource
settings applied.</para>
- <para>For units of type slice the only accepted value for
+ <para>For units of type slice, the only accepted value for
this setting is the parent slice. Since the name of a slice
- unit implies the parent slice it is hence redundant to ever
+ unit implies the parent slice, it is hence redundant to ever
set this parameter directly for slice units.</para>
</listitem>
</varlistentry>
but are only created programmatically using the bus interfaces of
systemd. They are named similar to filenames. A unit whose name
ends in <literal>.scope</literal> refers to a scope unit. Scopes
- units manage a set of system processes. Unlike service units scope
+ units manage a set of system processes. Unlike service units, scope
units manage externally created processes, and do not fork off
processes on its own.</para>
processes. This management is performed by creating a node in the
control group tree. Units that manage processes (primarilly scope
and service units) may be assigned to a specific slice. For each
- slice certain resource limits may the be set, that apply to all
+ slice, certain resource limits may the be set that apply to all
processes of all units contained in that slice. Slices are
organized hierarchially in a tree. The name of the slice encodes
- the location in the tree. The name consists of a "-" separated
+ the location in the tree. The name consists of a dash-separated
series of names, which describes the path to the slice from the
root slice. The root slice is named,
<filename>-.slice</filename>. Example:
the root slice <filename>-.slice</filename>.
</para>
- <para>By default service and scope units are placed in
+ <para>By default, service and scope units are placed in
<filename>system.slice</filename>, virtual machines and containers
registered with
<citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>1</manvolnum></citerefentry>
<varlistentry>
<term><filename>system.slice</filename></term>
<listitem>
- <para>By default all services
+ <para>By default, all services
services started by
<command>systemd</command> are
found in this slice.</para>
<varlistentry>
<term><filename>user.slice</filename></term>
<listitem>
- <para>By default all user
+ <para>By default, all user
processes and services started
on behalf of the user,
including the per-user systemd
<varlistentry>
<term><filename>machine.slice</filename></term>
<listitem>
- <para>By defalt all virtual
+ <para>By defalt, all virtual
machines and containers
registered with
<command>systemd-machined</command>
<listitem><para>A symbolic link is
created in the
<filename>.wants/</filename> or
- <filename>.requires/</filename> folder
+ <filename>.requires/</filename> directory
of the listed unit when this unit is
activated by <command>systemctl
enable</command>. This has the effect
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
however some are created automatically from other
configuration, dynamically from system state or
- programmatically at runtime. Units may be 'active'
- (meaning started, bound, plugged in, ... depending on
- the unit type, see below), or 'inactive' (meaning
+ programmatically at runtime. Units may be "active"
+ (meaning started, bound, plugged in, ..., depending on
+ the unit type, see below), or "inactive" (meaning
stopped, unbound, unplugged, ...), as well as in the
process of being activated or deactivated,
i.e. between the two states (these states are called
- 'activating', 'deactivating'). A special 'failed'
- state is available as well which is very similar to
- 'inactive' and is entered when the service failed in
+ "activating", "deactivating"). A special "failed"
+ state is available as well, which is very similar to
+ "inactive" and is entered when the service failed in
some way (process returned error code on exit, or
crashed, or an operation timed out). If this state is
- entered the cause will be logged, for later
+ entered, the cause will be logged, for later
reference. Note that the various unit types may have a
number of additional substates, which are mapped to
the five generalized unit states described
used to override a system-supplied hwdb file with a local file if needed;
a symlink in <filename>/etc</filename> with the same name as a rules file in
<filename>/lib</filename>, pointing to <filename>/dev/null</filename>,
- disables the rules file entirely. Hwdb files must have the extension
+ disables the rules file entirely. hwdb files must have the extension
<filename>.hwdb</filename>; other extensions are ignored.</para>
<para>The hwdb file contains data records consisting of matches and
~ianmdlvl / elogind.git / commitdiff