From: Lennart Poettering <lennart@poettering.net>
Date: Mon, 17 Feb 2014 15:37:30 +0000 (+0100)
Subject: Revert "man: systemd.service(5): clarify behavior of SuccessExitStatus"
X-Git-Tag: v209~95
X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=commitdiff_plain;h=4a3fa6ac77c5236f95963c0a0fdd541d02c6883a

Revert "man: systemd.service(5): clarify behavior of SuccessExitStatus"

This reverts commit 29e254f7f093c07a1ec7e845e60203357f585235.

Conflicts:
	man/systemd.service.xml
---

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 8ad665643..f3ba6574c 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -747,33 +747,30 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}</programlisting>
                                 <constant>SIGTERM</constant>, and <constant>SIGPIPE</constant>. Exit status
                                 definitions can either be numeric exit
                                 codes or termination signal names,
-                                separated by spaces. Signals will only
-                                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>
+                                separated by spaces. 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>
                         </varlistentry>
 
                         <varlistentry>