TXT).</para>
<para>The <option>--statistics</option> switch may be used to show resolver statistics, including information about
- the number of succesful and failed DNSSEC validations.</para>
+ the number of successful and failed DNSSEC validations.</para>
<para>The <option>--reset-statistics</option> may be used to reset various statistics counters maintained the
resolver, including those shown in the <option>--statistics</option> output. This operation requires root
domains specified here are preferably routed to the DNS servers configured for this interface. If a domain
name is prefixed with <literal>~</literal>, the domain name becomes a pure "routing" domain, is used for
DNS query routing purposes only and is not used in the described domain search logic. By specifying a
- routing domain of <literal>~.</literal> (the tilda indicating definition of a routing domain, the dot
+ routing domain of <literal>~.</literal> (the tilde indicating definition of a routing domain, the dot
referring to the DNS root domain which is the implied suffix of all valid DNS names) it is possible to
route all DNS traffic preferably to the DNS server specified for this interface. The route domain logic is
particularly useful on multi-homed hosts with DNS servers serving particular private DNS zones on each
<varlistentry>
<term><varname>UseDomains=</varname></term>
<listitem>
- <para>Takes a boolean argument, or a the special value <literal>route</literal>. When true, the domain name
+ <para>Takes a boolean argument, or the special value <literal>route</literal>. When true, the domain name
received from the DHCP server will be used as DNS search domain over this link, similar to the effect of
the <option>Domains=</option> setting. If set to <literal>route</literal>, the domain name received from
the DHCP server will be used for routing DNS queries only, but not for searching, similar to the effect of
asynchronous one.</para>
<para>Note that the commands specified in <varname>ExecStop=</varname> are only executed when the service
- started successfuly first. They are not invoked if the service was never started at all, or in case its
+ started successfully first. They are not invoked if the service was never started at all, or in case its
start-up failed, for example because any of the commands specified in <varname>ExecStart=</varname>,
<varname>ExecStartPre=</varname> or <varname>ExecStartPost=</varname> failed (and weren't prefixed with
<literal>-</literal>, see above) or timed out. Use <varname>ExecStopPost=</varname> to invoke commands when a
<term><filename>emergency.target</filename></term>
<listitem>
<para>A special target unit that starts an emergency shell on the main console. This target does not pull in
- any serices or mounts. It is the most minimal version of starting the system in order to acquire an
+ any services or mounts. It is the most minimal version of starting the system in order to acquire an
interactive shell; the only processes running are usually just the system manager (PID 1) and the shell
process. This unit is supposed to be used with the kernel command line option
<varname>systemd.unit=</varname>; it is also used when a file system check on a required file system fails,
<para>A special target unit that sets up all slice units (see
<citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
details) that shall be active after boot. By default the generic <filename>user.slice</filename>,
- <filename>system.slice</filename>, <filename>machines.slice</filename> slice units, as well as the the root
+ <filename>system.slice</filename>, <filename>machines.slice</filename> slice units, as well as the root
slice unit <filename>-.slice</filename> are pulled in and ordered before this unit (see below).</para>
<para>It's a good idea to add <varname>WantedBy=slices.target</varname> lines to the <literal>[Install]</literal>
projects / platform / upstream / systemd.git / commitdiff