<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>
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>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>
+
+
<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>
</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>
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>
-
- <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>
+
<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>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>
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
projects / thirdparty / systemd.git / commitdiff
