for the common options of all unit configuration
files. The common configuration items are configured
in the generic [Unit] and [Install] sections. A
- seperate [Device] section does not exist, since no
+ separate [Device] section does not exist, since no
device-specific options may be configured.</para>
<para>systemd will automatically create dynamic device
<listitem><para>Adds dependencies of
type <varname>Wants</varname> from
this unit to all listed units. This
- may be used to activate aritrary units
- if a specific device becomes
+ may be used to activate arbitrary units,
+ when a specific device becomes
available.</para></listitem>
</varlistentry>
<citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
<para>If an mount point is beneath another mount point
- in the file system hierarchy a dependency between both
+ in the file system hierarchy, a dependency between both
units is created automatically.</para>
<para>Mount points created at runtime independent on
which influence how dependencies are created for mount
points from <filename>/etc/fstab</filename>. If
<option>comment=systemd.mount</option> is specified as
- mount option then systemd will create a dependency of
+ mount option, then systemd will create a dependency of
type <option>Wants</option> from either
<filename>local-fs.target</filename> or
<filename>remote-fs.target</filename>, depending
for details.</para>
<para>If a mount point is configured in both
- <filename>/etc/fstab</filename> and a unit file the
+ <filename>/etc/fstab</filename> and a unit file, the
configuration in the latter takes precedence.</para>
</refsect1>
resource to mount. See
<citerefentry><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for details. If this refers to a
- device node a dependency on the
+ device node, a dependency on the
respective device unit is
automatically created. (See
<citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.)
<listitem><para>Takes an absolute path
of a directory of the mount point. If
the mount point is not existing at
- time of mounting it is created. This
+ time of mounting, it is created. This
string must be reflected in the unit
file name. (See above.) This option is
mandatory.</para></listitem>
<term><varname>TimeoutSec=</varname></term>
<listitem><para>Configures the time to
wait for the mount command to
- finish. If a comand does not exit
+ finish. If a command does not exit
within the configured time the mount
will be considered failed and be shut
down again. All commands still running
path specific configuration options are configured in
the [Path] section.</para>
- <para>For each path file a matching unit file must
+ <para>For each path file, a matching unit file must
exist, describing the unit to activate when the path
- changes. By default a service by the same name as the
+ changes. By default, a service by the same name as the
path (except for the suffix) is activated. Example: a
path file <filename>foo.path</filename> activates a
matching service <filename>foo.service</filename>. The
<para>Internally, path units use the
<citerefentry><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- API to monitor file systems. Due to that it suffers by the
+ API to monitor file systems. Due to that, it suffers by the
same limitations as inotify, and for example cannot be
used to monitor files or directories changed by other
machines on remote NFS file systems.</para>
<para>If an path unit is beneath another mount
- point in the file system hierarchy a dependency
+ point in the file system hierarchy, a dependency
between both units is created automatically.</para>
</refsect1>
<listitem><para>Defines paths to
monitor for certain changes:
<varname>PathExists=</varname> may be
- used to watch the mere existance of a
+ used to watch the mere existence of a
file or directory. If the file
specified exists the configured unit
is
unit whenever it changes or is
modified. <varname>DirectoryNotEmpty=</varname>
may be used to watch a directory and
- activate the configured unit whenver
+ activate the configured unit whenever
it contains at least one file.</para>
<para>The arguments of these
directory already is not empty (in
case of
<varname>DirectoryNotEmpty=</varname>)
- at the time the path unit is activated
+ at the time the path unit is activated,
then the configured unit is
immediately activated as
well. Something similar does not apply
changes. The argument is a unit name,
whose suffix is not
<filename>.path</filename>. If not
- specified this value defaults to a
+ specified, this value defaults to a
service that has the same name as the
path unit, except for the suffix. (See
above.) It is recommended that the
unit name that is activated and the
- unit name of the path unit is chosen
- identical except for the
+ unit name of the path unit are named
+ identical, except for the
suffix.</para></listitem>
</varlistentry>
</variablelist>
dynamically via <command>systemctl snapshot</command>
(see
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- for details) or an equivalent command. When created
+ for details) or an equivalent command. When created,
they will automatically get dependencies on the
- currently activated units. They hence act as saved
- runtime state of the systemd manager. Later on the
+ currently activated units. They act as saved
+ runtime state of the systemd manager. Later on, the
user may choose to return to the saved state via
- <command>systemctl isolate</command>. They are hence
+ <command>systemctl isolate</command>. They are
useful to roll back to a defined state after
temporarily starting/stopping services or
similar.</para>
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details) must exist, describing the service to
start on incoming traffic on the socket. Depending on
- the setting of <option>Accept=</option> (see below)
+ the setting of <option>Accept=</option> (see below),
this must either be named like the socket unit, but
with the suffix replaced; or it must be a template
file named the same way. Example: a socket file
connection.</para>
<para>Socket units may be used to implement on-demand
- starting of services as well as parallelized starting
+ starting of services, as well as parallelized starting
of services.</para>
</refsect1>
regardless whether there is incoming
traffic on them or not.</para>
- <para>If an IP address is used here it
+ <para>If an IP address is used here, it
is often desirable to listen on it
before the interface it is configured
on is up and running, and even
interfaces. This controls the
SO_BINDTODEVICE socket option (see
<citerefentry><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- for details). If this option is used
+ for details). If this option is used,
an automatic dependency from this
socket unit on the network interface
device unit
<varlistentry>
<term><varname>DirectoryMode=</varname></term>
<listitem><para>If listening on a file
- system socket of FIFO the parent
+ system socket of FIFO, the parent
directories are automatically created
if needed. This option specifies the
file system access mode used when
<varlistentry>
<term><varname>SocketMode=</varname></term>
<listitem><para>If listening on a file
- system socket of FIFO this option
+ system socket of FIFO, this option
specifies the file system access mode
used when creating the file
node. Defaults to
<varlistentry>
<term><varname>Accept=</varname></term>
<listitem><para>Takes a boolean
- argument. If true a service instance
+ argument. If true, a service instance
is spawned for each incoming
connection and only the connection
- socket is passed to it. If false all
+ socket is passed to it. If false, all
listening sockets themselves are
passed to the started service unit,
and only one service unit is spawned
for all connections (also see
above). This value is ignored for
datagram sockets and FIFOs where
- unconditionally a single service unit
+ a single service unit unconditionally
handles all incoming traffic. Defaults
to <option>false</option>. For
- performance reasons it is recommended
+ performance reasons, it is recommended
to write new daemons only in a way
that is suitable for
<option>Accept=false</option>. This
option is mostly useful to allow
daemons designed for usage with
- <citerefentry><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- to work unmodified with system socket
+ <citerefentry><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+ to work unmodified with systemd socket
activation.</para></listitem>
</varlistentry>
services instances for, when
<option>Accept=true</option> is
set. If more concurrent connections
- are coming in they will be refused,
+ are coming in, they will be refused
until at least one existing connection
is terminated. This setting has no
effect for sockets configured with
<varlistentry>
<term><varname>ExecStartPre=</varname></term>
<term><varname>ExecStartPost=</varname></term>
- <listitem><para>Takes a command line
- that is executed before (resp. after)
+ <listitem><para>Takes a command line,
+ which is executed before (resp. after)
the listening sockets/FIFOs are created and
bound. The first token of the command
line must be an absolute file name,
then followed by arguments for the
process. If specified more than once,
all commands are executed one after
- the other, serially. Use of these
- settings is optional.</para></listitem>
+ the other, fully serialized. The use of
+ these settings is optional.</para></listitem>
</varlistentry>
<varlistentry>
the listening sockets/FIFOs are closed
and removed. If specified more than
once, all commands are executed one
- after the other, serially. Use of
- these settings is
- optional.</para></listitem>
+ after the other, fully serialized. The use of
+ these settings is optional.</para></listitem>
</varlistentry>
<varlistentry>
<varname>ExecStartPost=</varname>,
<varname>ExecStopPre=</varname> and
<varname>ExecStopPost=</varname> to
- finish. If a comand does not exit
- within the configured time the socket
+ finish. If a command does not exit
+ within the configured time, the socket
will be considered failed and be shut
- down again. All commands still running
+ down again. All commands still running,
will be terminated forcibly via
SIGTERM, and after another delay of
this time with SIGKILL. (See
paging. See
<citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for details. If this refers to a
- device node a dependency on the
+ device node, a dependency on the
respective device unit is
automatically created. (See
<citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for more information.) If this refers
- to a file a dependency on the
+ to a file, a dependency on the
respective mount unit is automatically
created. (See
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for the common options of all unit configuration
files. The common configuration items are configured
in the generic [Unit] and [Install] sections. A
- seperate [Target] section does not exist, since no
+ separate [Target] section does not exist, since no
target-specific options may be configured.</para>
<para>Target units do not offer any additional
provided by units. They exist merely to group units via dependencies
(useful as boot targets), and to establish
standardized names for synchronization points used in
- dependencies between units. Among other things target
+ dependencies between units. Among other things, target
units are a more flexible replacement for SysV
- runlevels in the classic SysV init system. (And in
- fact for compatibility reasons there exist special
+ runlevels in the classic SysV init system. (And for
+ compatibility reasons there exist special
target units such as
- <filename>runlevel3.target</filename> that are used by
+ <filename>runlevel3.target</filename> which are used by
the SysV runlevel compatibility code in systemd. See
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
for details).</para>
timer specific configuration options are configured in
the [Timer] section.</para>
- <para>For each timer file a matching unit file must
+ <para>For each timer file, a matching unit file must
exist, describing the unit to activate when the timer
- elapses. By default a service by the same name as the
+ elapses. By default, a service by the same name as the
timer (except for the suffix) is activated. Example: a
timer file <filename>foo.timer</filename> activates a
matching service <filename>foo.service</filename>. The
deactivated.</para>
<para>Multiple directives may be
- combined, of the same and of different
+ combined of the same and of different
types. For example, by combining
<varname>OnBoot=</varname> and
<varname>OnUnitActive=</varname> it is
directives.</para></listitem>
<para>These are monotonic timers,
- independant of wall-clock time and timezones. If the
+ independent of wall-clock time and timezones. If the
computer is temporarily suspended, the
monotonic clock stops too.</para>
when this timer elapses. The argument is a
unit name, whose suffix is not
<filename>.timer</filename>. If not
- specified this value defaults to a
+ specified, this value defaults to a
service that has the same name as the
timer unit, except for the
- suffix. (See above.) It is recommended
+ suffix. (See above.) It is recommended,
that the unit name that is activated
and the unit name of the timer unit
- is chosen identical except for the
+ are named identical, except for the
suffix.</para></listitem>
</varlistentry>
</variablelist>
<para>Time span values encoded in unit files can be
written in various formats. A stand-alone number
specifies a time in seconds. If suffixed with a time
- unit, the unit is honored. A concatentation of
+ unit, the unit is honored. A concatenation of
multiple value with units is supported, in which case
the values are added up. Example: "50" refers to 50
seconds; "2min 200ms" refers to 2 minutes plus 200
projects / systemd / commitdiff