]> git.ipfire.org Git - thirdparty/systemd.git/blobdiff - man/systemd.service.xml
Merge pull request #7625 from thom311/th/const-strlen
[thirdparty/systemd.git] / man / systemd.service.xml
index 1372cc972a16e9e9341dc6fd58c18f37eb664fc5..ada92369e1b41afcd9c83eece82e01720f92a9d7 100644 (file)
@@ -3,6 +3,8 @@
   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 
 <!--
+  SPDX-License-Identifier: LGPL-2.1+
+
   This file is part of systemd.
 
   Copyright 2010 Lennart Poettering
   </refsect1>
 
   <refsect1>
-    <title>Automatic Dependencies</title>
-
-    <para>Services with <varname>Type=dbus</varname> set automatically
-    acquire dependencies of type <varname>Requires=</varname> and
-    <varname>After=</varname> on
-    <filename>dbus.socket</filename>.</para>
-
-    <para>Socket activated services are automatically ordered after
-    their activating <filename>.socket</filename> units via an
-    automatic <varname>After=</varname> dependency.
-    Services also pull in all <filename>.socket</filename> units
-    listed in <varname>Sockets=</varname> via automatic
-    <varname>Wants=</varname> and <varname>After=</varname> dependencies.</para>
-
-    <para>Unless <varname>DefaultDependencies=</varname> in the <literal>[Unit]</literal> is set to
-    <option>false</option>, service units will implicitly have dependencies of type <varname>Requires=</varname> and
-    <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>After=</varname> on
-    <filename>basic.target</filename> as well as dependencies of type <varname>Conflicts=</varname> and
-    <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure that normal service units pull in
-    basic system initialization, and are terminated cleanly prior to system shutdown. Only services involved with early
-    boot or late system shutdown should disable this option.</para>
-
-    <para>Instanced service units (i.e. service units with an <literal>@</literal> in their name) are assigned by
-    default a per-template slice unit (see
-    <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>), named after the
-    template unit, containing all instances of the specific template. This slice is normally stopped at shutdown,
-    together with all template instances. If that is not desired, set <varname>DefaultDependencies=no</varname> in the
-    template unit, and either define your own per-template slice unit file that also sets
-    <varname>DefaultDependencies=no</varname>, or set <varname>Slice=system.slice</varname> (or another suitable slice)
-    in the template unit. Also see
-    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+    <title>Implicit Dependencies</title>
+
+    <para>The following dependencies are implicitly added:</para>
+
+    <itemizedlist>
+      <listitem><para>Services with <varname>Type=dbus</varname> set automatically
+      acquire dependencies of type <varname>Requires=</varname> and
+      <varname>After=</varname> on
+      <filename>dbus.socket</filename>.</para></listitem>
+
+      <listitem><para>Socket activated services are automatically ordered after
+      their activating <filename>.socket</filename> units via an
+      automatic <varname>After=</varname> dependency.
+      Services also pull in all <filename>.socket</filename> units
+      listed in <varname>Sockets=</varname> via automatic
+      <varname>Wants=</varname> and <varname>After=</varname> dependencies.</para></listitem>
+    </itemizedlist>
 
     <para>Additional implicit dependencies may be added as result of
     execution and resource control parameters as documented in
     <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
   </refsect1>
 
+  <refsect1>
+    <title>Default Dependencies</title>
+
+    <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+    <itemizedlist>
+      <listitem><para>Service units will have dependencies of type <varname>Requires=</varname> and
+      <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>After=</varname> on
+      <filename>basic.target</filename> as well as dependencies of type <varname>Conflicts=</varname> and
+      <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure that normal service units pull in
+      basic system initialization, and are terminated cleanly prior to system shutdown. Only services involved with early
+      boot or late system shutdown should disable this option.</para></listitem>
+
+      <listitem><para>Instanced service units (i.e. service units with an <literal>@</literal> in their name) are assigned by
+      default a per-template slice unit (see
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>), named after the
+      template unit, containing all instances of the specific template. This slice is normally stopped at shutdown,
+      together with all template instances. If that is not desired, set <varname>DefaultDependencies=no</varname> in the
+      template unit, and either define your own per-template slice unit file that also sets
+      <varname>DefaultDependencies=no</varname>, or set <varname>Slice=system.slice</varname> (or another suitable slice)
+      in the template unit. Also see
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+      </para></listitem>
+    </itemizedlist>
+  </refsect1>
+
   <refsect1>
     <title>Options</title>
 
       <varlistentry>
         <term><varname>PIDFile=</varname></term>
 
-        <listitem><para>Takes an absolute file name pointing to the
+        <listitem><para>Takes an absolute filename pointing to the
         PID file of this daemon. Use of this option is recommended for
         services where <varname>Type=</varname> is set to
         <option>forking</option>. systemd will read the PID of the
         <varname>ExecStop=</varname> are not valid.)</para>
 
         <para>For each of the specified commands, the first argument must be an absolute path to an
-        executable. Optionally, if this file name is prefixed with <literal>@</literal>, the second token will be
-        passed as <literal>argv[0]</literal> to the executed process, followed by the further arguments specified.  If
-        the absolute filename is prefixed with <literal>-</literal>, an exit code of the command normally considered a
-        failure (i.e. non-zero exit status or abnormal exit due to signal) is ignored and considered success.  If the
-        absolute path is prefixed with <literal>+</literal> then it is executed with full
-        privileges. <literal>@</literal>, <literal>-</literal>, and <literal>+</literal> may be used together and they
-        can appear in any order.</para>
+        executable. Optionally, this filename may be prefixed with a number of special characters:</para>
+
+        <table>
+          <title>Special executable prefixes</title>
+
+          <tgroup cols='2'>
+            <colspec colname='prefix'/>
+            <colspec colname='meaning'/>
+
+            <thead>
+              <row>
+                <entry>Prefix</entry>
+                <entry>Effect</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry><literal>@</literal></entry>
+                <entry>If the executable path is prefixed with <literal>@</literal>, the second specified token will be passed as <literal>argv[0]</literal> to the executed process (instead of the actual filename), followed by the further arguments specified.</entry>
+              </row>
+
+              <row>
+                <entry><literal>-</literal></entry>
+                <entry>If the executable path is prefixed with <literal>-</literal>, an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is ignored and considered success.</entry>
+              </row>
+
+              <row>
+                <entry><literal>+</literal></entry>
+                <entry>If the executable path is prefixed with <literal>+</literal> then the process is executed with full privileges. In this mode privilege restrictions configured with <varname>User=</varname>, <varname>Group=</varname>, <varname>CapabilityBoundingSet=</varname> or the various file system namespacing options (such as <varname>PrivateDevices=</varname>, <varname>PrivateTmp=</varname>) are not applied to the invoked command line (but still affect any other <varname>ExecStart=</varname>, <varname>ExecStop=</varname>, … lines).</entry>
+              </row>
+
+              <row>
+                <entry><literal>!</literal></entry>
+
+                <entry>Similar to the <literal>+</literal> character discussed above this permits invoking command lines with elevated privileges. However, unlike <literal>+</literal> the <literal>!</literal> character exclusively alters the effect of <varname>User=</varname>, <varname>Group=</varname> and <varname>SupplementaryGroups=</varname>, i.e. only the stanzas the affect user and group credentials. Note that this setting may be combined with <varname>DynamicUser=</varname>, in which case a dynamic user/group pair is allocated before the command is invoked, but credential changing is left to the executed process itself.</entry>
+              </row>
+
+              <row>
+                <entry><literal>!!</literal></entry>
+
+                <entry>This prefix is very similar to <literal>!</literal>, however it only has an effect on systems lacking support for ambient process capabilities, i.e. without support for <varname>AmbientCapabilities=</varname>. It's intended to be used for unit files that take benefit of ambient capabilities to run processes with minimal privileges wherever possible while remaining compatible with systems that lack ambient capabilities support. Note that when <literal>!!</literal> is used, and a system lacking ambient capability support is detected any configured <varname>SystemCallFilter=</varname> and <varname>CapabilityBoundingSet=</varname> stanzas are implicitly modified, in order to permit spawned processes to drop credentials and capabilities themselves, even if this is configured to not be allowed. Moreover, if this prefix is used and a system lacking ambient capability support is detected <varname>AmbientCapabilities=</varname> will be skipped and not be applied. On systems supporting ambient capabilities, <literal>!!</literal> has no effect and is redundant.</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+        <para><literal>@</literal>, <literal>-</literal>, and one of
+        <literal>+</literal>/<literal>!</literal>/<literal>!!</literal> may be used together and they can appear in any
+        order. However, only one of <literal>+</literal>, <literal>!</literal>, <literal>!!</literal> may be used at a
+        time. Note that these prefixes are also supported for the other command line settings,
+        i.e. <varname>ExecStartPre=</varname>, <varname>ExecStartPost=</varname>, <varname>ExecReload=</varname>,
+        <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname>.</para>
 
         <para>If more than one command is specified, the commands are
         invoked sequentially in the order they appear in the unit
         all <varname>ExecStartPre=</varname> commands that were not prefixed
         with a <literal>-</literal> exit successfully.</para>
 
-        <para><varname>ExecStartPost=</varname> commands are only run after
-        the service has started successfully, as determined by <varname>Type=</varname>
-        (i.e. the process has been started for <varname>Type=simple</varname>
-        or <varname>Type=idle</varname>, the process exits successfully for
-        <varname>Type=oneshot</varname>, the initial process exits successfully
-        for <varname>Type=forking</varname>, <literal>READY=1</literal> is sent
-        for <varname>Type=notify</varname>, or the <varname>BusName=</varname>
-        has been taken for <varname>Type=dbus</varname>).</para>
+        <para><varname>ExecStartPost=</varname> commands are only run after the commands specified in
+        <varname>ExecStart=</varname> have been invoked successfully, as determined by <varname>Type=</varname>
+        (i.e. the process has been started for <varname>Type=simple</varname> or <varname>Type=idle</varname>, the last
+        <varname>ExecStart=</varname> process exited successfully for <varname>Type=oneshot</varname>, the initial
+        process exited successfully for <varname>Type=forking</varname>, <literal>READY=1</literal> is sent for
+        <varname>Type=notify</varname>, or the <varname>BusName=</varname> has been taken for
+        <varname>Type=dbus</varname>).</para>
 
         <para>Note that <varname>ExecStartPre=</varname> may not be
         used to start long-running processes. All processes forked
         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
-        service failed to start up correctly and is shut down again.</para>
+        service failed to start up correctly and is shut down again. Also note that, service restart requests are
+        implemented as stop operations followed by start operations. This means that <varname>ExecStop=</varname> and
+        <varname>ExecStopPost=</varname> are executed during a service restart operation.</para>
 
         <para>It is recommended to use this setting for commands that communicate with the service requesting clean
         termination. When the commands specified with this option are executed it should be assumed that the service is
         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
 
       <varlistentry>
         <term><varname>NonBlocking=</varname></term>
-        <listitem><para>Set the <constant>O_NONBLOCK</constant> flag
-        for all file descriptors passed via socket-based activation.
-        If true, all file descriptors >= 3 (i.e. all except stdin,
-        stdout, and stderr) will have the
-        <constant>O_NONBLOCK</constant> flag set and hence are in
-        non-blocking mode. This option is only useful in conjunction
-        with a socket unit, as described in
-        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
-        Defaults to false.</para></listitem>
+        <listitem><para>Set the <constant>O_NONBLOCK</constant> flag for all file descriptors passed via socket-based
+        activation. If true, all file descriptors >= 3 (i.e. all except stdin, stdout, stderr), excluding those passed
+        in via the file descriptor storage logic (see <varname>FileDescriptorStoreMax=</varname> for details), will
+        have the <constant>O_NONBLOCK</constant> flag set and hence are in non-blocking mode. This option is only
+        useful in conjunction with a socket unit, as described in
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> and has no
+        effect on file descriptors which were previously saved in the file-descriptor store for example.  Defaults to
+        false.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         effect.</para></listitem>
       </varlistentry>
 
-      <varlistentry>
-        <term><varname>FailureAction=</varname></term>
-        <listitem><para>Configure the action to take when the service enters a failed state. Takes the same values as
-        the unit setting <varname>StartLimitAction=</varname> and executes the same actions (see
-        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>). Defaults to
-        <option>none</option>. </para></listitem>
-      </varlistentry>
-
       <varlistentry>
         <term><varname>FileDescriptorStoreMax=</varname></term>
-        <listitem><para>Configure how many file descriptors may be
-        stored in the service manager for the service using
+        <listitem><para>Configure how many file descriptors may be stored in the service manager for the service using
         <citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s
-        <literal>FDSTORE=1</literal> messages. This is useful for
-        implementing service restart schemes where the state is
-        serialized to <filename>/run</filename> and the file
-        descriptors passed to the service manager, to allow restarts
-        without losing state. Defaults to 0, i.e. no file descriptors
-        may be stored in the service manager. All file
-        descriptors passed to the service manager from a specific
-        service are passed back to the service's main process on the
-        next service restart. Any file descriptors passed to the
-        service manager are automatically closed when POLLHUP or
-        POLLERR is seen on them, or when the service is fully stopped
-        and no job is queued or being executed for it.</para></listitem>
+        <literal>FDSTORE=1</literal> messages. This is useful for implementing services that can restart after an
+        explicit request or a crash without losing state. Any open sockets and other file descriptors which should not
+        be closed during the restart may be stored this way. Application state can either be serialized to a file in
+        <filename>/run</filename>, or better, stored in a
+        <citerefentry><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry> memory file
+        descriptor. Defaults to 0, i.e. no file descriptors may be stored in the service manager. All file descriptors
+        passed to the service manager from a specific service are passed back to the service's main process on the next
+        service restart. Any file descriptors passed to the service manager are automatically closed when
+        <constant>POLLHUP</constant> or <constant>POLLERR</constant> is seen on them, or when the service is fully
+        stopped and no job is queued or being executed for it.</para></listitem>
       </varlistentry>
 
       <varlistentry>
 
     <para>Each command line is split on whitespace, with the first item being the command to
     execute, and the subsequent items being the arguments. Double quotes ("…") and single quotes
-    ('…') may be used, in which case everything until the next matching quote becomes part of the
-    same argument. Quotes themselves are removed. C-style escapes are also supported. The table
-    below contains the list of known escape patterns. Only escape patterns which match the syntax in
-    the table are allowed; other patterns may be added in the future and unknown patterns will
-    result in a warning. In particular, any backslashes should be doubled. Finally, a trailing
-    backslash (<literal>\</literal>) may be used to merge lines.</para>
+    ('…') may be used to wrap a whole item (the opening quote may appear only at the beginning or
+    after whitespace that is not quoted, and the closing quote must be followed by whitespace or the
+    end of line), in which case everything until the next matching quote becomes part of the same
+    argument. Quotes themselves are removed. C-style escapes are also supported. The table below
+    contains the list of known escape patterns. Only escape patterns which match the syntax in the
+    table are allowed; other patterns may be added in the future and unknown patterns will result in
+    a warning. In particular, any backslashes should be doubled. Finally, a trailing backslash
+    (<literal>\</literal>) may be used to merge lines.</para>
 
     <para>This syntax is inspired by shell syntax, but only the meta-characters and expansions
     described in the following paragraphs are understood, and the expansion of variables is