man: use spaces instead of tabs
Several sections of the man pages included intermixed tabs and spaces; this commit replaces all tabs with spaces.
This commit is contained in:
Jason St. John
Zbigniew Jędrzejewski-Szmek
parent
6db2742802
commit
b200a92cdc
|
|
@ -305,7 +305,7 @@
|
|||
|
||||
<listitem><para>Use TrueCrypt in system
|
||||
encryption mode. This implies
|
||||
<varname>tcrypt</varname>.</para></listitem>
|
||||
<varname>tcrypt</varname>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
|
|
|||
|
|
@ -385,7 +385,7 @@ along with systemd; If not, see <http://www.gnu.org/licenses/>.
|
|||
|
||||
<listitem><para>Given field is not available in
|
||||
<parameter>c</parameter>.</para>
|
||||
</listitem>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
|
@ -399,7 +399,7 @@ along with systemd; If not, see <http://www.gnu.org/licenses/>.
|
|||
<function>sd_bus_get_owner_uid</function> if the sender is not
|
||||
part of a systemd system unit, systemd user unit, systemd
|
||||
slice, logind session, or a systemd user session.</para>
|
||||
</listitem>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
|
|
|||
|
|
@ -50,8 +50,8 @@
|
|||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>systemd-delta</command>
|
||||
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
||||
<arg choice="opt" rep="repeat"><replaceable>PREFIX</replaceable><optional>/<replaceable>SUFFIX</replaceable></optional>|<replaceable>SUFFIX</replaceable></arg>
|
||||
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
||||
<arg choice="opt" rep="repeat"><replaceable>PREFIX</replaceable><optional>/<replaceable>SUFFIX</replaceable></optional>|<replaceable>SUFFIX</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
|
|
@ -78,27 +78,27 @@
|
|||
the name of the main configuration file, must match).
|
||||
For a fuller explanation, see
|
||||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
||||
</para>
|
||||
</para>
|
||||
|
||||
<para>The command line argument will be split into a
|
||||
prefix and a suffix. Either is optional. The prefix
|
||||
must be one of the directories containing
|
||||
configuration files (<filename>/etc</filename>,
|
||||
<filename>/run</filename>,
|
||||
<filename>/usr/lib</filename>, ...). If it is given,
|
||||
only overriding files contained in this directory will
|
||||
be shown. Otherwise, all overriding files will be
|
||||
shown. The suffix must be a name of a subdirectory
|
||||
containing configuration files like
|
||||
<filename>tmpfiles.d</filename>,
|
||||
<filename>sysctl.d</filename> or
|
||||
<filename>systemd/system</filename>. If it is given,
|
||||
only configuration files in this subdirectory (across
|
||||
all configuration paths) will be analyzed. Otherwise,
|
||||
all configuration files will be analyzed. If the
|
||||
commandline argument is not given at all, all
|
||||
configuration files will be analyzed. See below for
|
||||
some examples.</para>
|
||||
<para>The command line argument will be split into a
|
||||
prefix and a suffix. Either is optional. The prefix
|
||||
must be one of the directories containing
|
||||
configuration files (<filename>/etc</filename>,
|
||||
<filename>/run</filename>,
|
||||
<filename>/usr/lib</filename>, ...). If it is given,
|
||||
only overriding files contained in this directory will
|
||||
be shown. Otherwise, all overriding files will be
|
||||
shown. The suffix must be a name of a subdirectory
|
||||
containing configuration files like
|
||||
<filename>tmpfiles.d</filename>,
|
||||
<filename>sysctl.d</filename> or
|
||||
<filename>systemd/system</filename>. If it is given,
|
||||
only configuration files in this subdirectory (across
|
||||
all configuration paths) will be analyzed. Otherwise,
|
||||
all configuration files will be analyzed. If the
|
||||
commandline argument is not given at all, all
|
||||
configuration files will be analyzed. See below for
|
||||
some examples.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
|
@ -200,21 +200,21 @@
|
|||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Examples</title>
|
||||
<refsect1>
|
||||
<title>Examples</title>
|
||||
|
||||
<para>To see all local configuration:</para>
|
||||
<programlisting>systemd-delta</programlisting>
|
||||
<para>To see all local configuration:</para>
|
||||
<programlisting>systemd-delta</programlisting>
|
||||
|
||||
<para>To see all runtime configuration:</para>
|
||||
<programlisting>systemd-delta /run</programlisting>
|
||||
<para>To see all runtime configuration:</para>
|
||||
<programlisting>systemd-delta /run</programlisting>
|
||||
|
||||
<para>To see all system unit configuration changes:</para>
|
||||
<programlisting>systemd-delta systemd/system</programlisting>
|
||||
<para>To see all system unit configuration changes:</para>
|
||||
<programlisting>systemd-delta systemd/system</programlisting>
|
||||
|
||||
<para>To see all runtime "drop-in" changes for system units:</para>
|
||||
<programlisting>systemd-delta --type=extended /run/systemd/system</programlisting>
|
||||
</refsect1>
|
||||
<para>To see all runtime "drop-in" changes for system units:</para>
|
||||
<programlisting>systemd-delta --type=extended /run/systemd/system</programlisting>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Exit status</title>
|
||||
|
|
|
|||
|
|
@ -751,29 +751,29 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}</programlisting>
|
|||
be considered if the service does not implement
|
||||
a signal handler and exits as a direct result
|
||||
of receiving the signal. For example:
|
||||
<programlisting>SuccessExitStatus=1 2 8 <constant>SIGKILL</constant></programlisting>
|
||||
ensures that exit codes 1, 2, 8 and
|
||||
the termination signal
|
||||
<constant>SIGKILL</constant> are
|
||||
considered clean service terminations.
|
||||
</para>
|
||||
<programlisting>SuccessExitStatus=1 2 8 <constant>SIGKILL</constant></programlisting>
|
||||
ensures that exit codes 1, 2, 8 and
|
||||
the termination signal
|
||||
<constant>SIGKILL</constant> are
|
||||
considered clean service terminations.
|
||||
</para>
|
||||
|
||||
<para>Note that if a process has a
|
||||
signal handler installed and exits by
|
||||
calling
|
||||
<citerefentry><refentrytitle>_exit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
||||
in response to a signal, the
|
||||
information about the signal is lost.
|
||||
Programs should instead perform cleanup and kill themselves with the same signal instead. See
|
||||
<ulink url="http://www.cons.org/cracauer/sigint.html">Proper handling of SIGINT/SIGQUIT — How to be a proper program</ulink>.</para>
|
||||
<para>Note that if a process has a
|
||||
signal handler installed and exits by
|
||||
calling
|
||||
<citerefentry><refentrytitle>_exit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
||||
in response to a signal, the
|
||||
information about the signal is lost.
|
||||
Programs should instead perform cleanup and kill themselves with the same signal instead. See
|
||||
<ulink url="http://www.cons.org/cracauer/sigint.html">Proper handling of SIGINT/SIGQUIT — How to be a proper program</ulink>.</para>
|
||||
|
||||
<para>This option may appear more than once
|
||||
in which case the list of successful
|
||||
exit statuses is merged. If the empty
|
||||
string is assigned to this option, the
|
||||
list is reset, all prior assignments
|
||||
of this option will have no
|
||||
effect.</para></listitem>
|
||||
<para>This option may appear more than once
|
||||
in which case the list of successful
|
||||
exit statuses is merged. If the empty
|
||||
string is assigned to this option, the
|
||||
list is reset, all prior assignments
|
||||
of this option will have no
|
||||
effect.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
|
|
|||
|
|
@ -121,16 +121,16 @@
|
|||
boot or late system shutdown should disable this
|
||||
option.</para>
|
||||
|
||||
<para>Socket units will have a
|
||||
<varname>Before=</varname> dependency on the service
|
||||
which they trigger added implicitly. No implicit
|
||||
<varname>WantedBy=</varname> or
|
||||
<varname>RequiredBy=</varname> dependency from the
|
||||
socket to the service is added. This means that the
|
||||
service may be started without the socket, in which
|
||||
case it must be able to open sockets by itself. To
|
||||
prevent this, an explicit <varname>Requires=</varname>
|
||||
dependency may be added.</para>
|
||||
<para>Socket units will have a
|
||||
<varname>Before=</varname> dependency on the service
|
||||
which they trigger added implicitly. No implicit
|
||||
<varname>WantedBy=</varname> or
|
||||
<varname>RequiredBy=</varname> dependency from the
|
||||
socket to the service is added. This means that the
|
||||
service may be started without the socket, in which
|
||||
case it must be able to open sockets by itself. To
|
||||
prevent this, an explicit <varname>Requires=</varname>
|
||||
dependency may be added.</para>
|
||||
|
||||
<para>Socket units may be used to implement on-demand
|
||||
starting of services, as well as parallelized starting
|
||||
|
|
|
|||
Loading…
Reference in New Issue