<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
- "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+ "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
-<refentry id="systemd.service">
+<refentry id="systemd.service" xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>systemd.service</title>
<productname>systemd</productname>
<option>notify-reload</option>, or <option>idle</option>:</para>
<itemizedlist>
- <listitem><para>If set to <option>simple</option> (the default if <varname>ExecStart=</varname> is
- specified but neither <varname>Type=</varname> nor <varname>BusName=</varname> are), the service manager
- will consider the unit started immediately after the main service process has been forked off.
- <emphasis>The use of this type is discouraged, use <option>exec</option> instead.
- </emphasis></para>
+ <listitem><para>If set to <option>simple</option> (the default if <varname>ExecStart=</varname>
+ is specified but neither <varname>Type=</varname> nor <varname>BusName=</varname> are), the
+ service manager will consider the unit started immediately after the main service process has
+ been forked off (i.e. immediately after <function>fork()</function>, and before various process
+ attributes have been configured and in particular before the new process has called
+ <function>execve()</function> to invoke the actual service binary). Typically,
+ <varname>Type=</varname><option>exec</option> is the better choice, see below.</para>
<para>It is expected that the process configured with <varname>ExecStart=</varname> is the main
process of the service. In this mode, if the process offers functionality to other processes on
socket provided by systemd. If <varname>NotifyAccess=</varname> is missing or set to
<option>none</option>, it will be forcibly set to <option>main</option>.</para>
- <para>If the service supports reloading, and uses the a signal to start the reload, using
+ <para>If the service supports reloading, and uses a signal to start the reload, using
<option>notify-reload</option> instead is recommended.</para></listitem>
<listitem><para>Behavior of <option>notify-reload</option> is similar to <option>notify</option>,
anyway.</para></listitem>
</itemizedlist>
- <para>It is generally recommended to use <varname>Type=</varname><option>exec</option> for
- long-running services whenever possible, as it is the simplest and fastest option. However, as this
- service type won't propagate service start-up failures and doesn't allow ordering of other units
- against completion of initialization of the service (which for example is useful if clients need to
- connect to the service through some form of IPC, and the IPC channel is only established by the
- service itself — in contrast to doing this ahead of time through socket or bus activation or
- similar), it might not be sufficient for many cases. If so, <option>notify</option>,
+ <para>It is recommended to use <varname>Type=</varname><option>exec</option> for long-running
+ services, as it ensures that process setup errors (e.g. errors such as a missing service
+ executable, or missing user) are properly tracked. However, as this service type won't propagate
+ the failures in the service's own startup code (as opposed to failures in the preparatory steps the
+ service manager executes before <function>execve()</function>) and doesn't allow ordering of other
+ units against completion of initialization of the service code itself (which for example is useful
+ if clients need to connect to the service through some form of IPC, and the IPC channel is only
+ established by the service itself — in contrast to doing this ahead of time through socket or bus
+ activation or similar), it might not be sufficient for many cases. If so, <option>notify</option>,
<option>notify-reload</option>, or <option>dbus</option> (the latter only in case the service
provides a D-Bus interface) are the preferred options as they allow service program code to
precisely schedule when to consider the service started up successfully and when to proceed with
explicit support in the service codebase (as <function>sd_notify()</function> or an equivalent API
needs to be invoked by the service at the appropriate time) — if it's not supported, then
<option>forking</option> is an alternative: it supports the traditional heavy-weight UNIX service
- start-up protocol. Note that using any type other than
- <option>simple</option>/<option>exec</option> possibly delays the boot process, as the service
- manager needs to wait for service initialization to complete. (Also note it is generally not
- recommended to use <option>idle</option> or <option>oneshot</option> for long-running services.)
- </para>
- </listitem>
+ start-up protocol. Note that using any type other than <option>simple</option> possibly delays the
+ boot process, as the service manager needs to wait for at least some service initialization to
+ complete. (Also note it is generally not recommended to use <option>idle</option> or
+ <option>oneshot</option> for long-running services.)</para>
+
+ <para>Note that various service settings (e.g. <varname>User=</varname>, <varname>Group=</varname>
+ through libc NSS) might result in "hidden" blocking IPC calls to other services when
+ used. Sometimes it might be advisable to use the <option>simple</option> service type to ensure
+ that the service manager's transaction logic is not affected by such potentially slow operations
+ and hidden dependencies, as this is the only service type where the service manager will not wait
+ for such service execution setup operations to complete before proceeding.</para></listitem>
</varlistentry>
<varlistentry>
<option>cgroup</option> is meant for applications whose forking model is not known ahead of time and which
might not have a specific main process. It is well suited for transient or automatically generated services,
such as graphical applications inside of a desktop environment.</para>
+
+ <xi:include href="version-info.xml" xpointer="v250"/>
</listitem>
</varlistentry>
also applies to <varname>ExecCondition=</varname>. <varname>ExecCondition=</varname> will also run the commands
in <varname>ExecStopPost=</varname>, as part of stopping the service, in the case of any non-zero or abnormal
exits, like the ones described above.</para>
+
+ <xi:include href="version-info.xml" xpointer="v243"/>
</listitem>
</varlistentry>
of auto-restarts from <varname>RestartSec=</varname> to <varname>RestartMaxDelaySec=</varname>.
Takes a positive integer or 0 to disable it. Defaults to 0.</para>
- <para>This setting is effective only if <varname>RestartMaxDelaySec=</varname> is also set.</para></listitem>
+ <para>This setting is effective only if <varname>RestartMaxDelaySec=</varname> is also set.</para>
+
+ <xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>
<varlistentry>
in the same format as <varname>RestartSec=</varname>, or <literal>infinity</literal>
to disable the setting. Defaults to <literal>infinity</literal>.</para>
- <para>This setting is effective only if <varname>RestartSteps=</varname> is also set.</para></listitem>
+ <para>This setting is effective only if <varname>RestartSteps=</varname> is also set.</para>
+
+ <xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>
<varlistentry>
provided the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified
until the service startup status is finished by <literal>READY=1</literal>. (see
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
- </para></listitem>
+ </para>
+
+ <xi:include href="version-info.xml" xpointer="v188"/></listitem>
</varlistentry>
<varlistentry>
provided the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified,
or terminates itself (see
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
- </para></listitem>
+ </para>
+
+ <xi:include href="version-info.xml" xpointer="v188"/></listitem>
</varlistentry>
<varlistentry>
provided the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified,
or terminates itself (see
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
- </para></listitem>
+ </para>
+
+ <xi:include href="version-info.xml" xpointer="v243"/></listitem>
</varlistentry>
<varlistentry>
By using <option>kill</option> the service is immediately terminated by sending
<varname>FinalKillSignal=</varname> without any further timeout. This setting can be used to expedite the
shutdown of failing services.
- </para></listitem>
+ </para>
+
+ <xi:include href="version-info.xml" xpointer="v246"/></listitem>
</varlistentry>
<varlistentry>
provided the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified
until the service shutdown is achieved by <literal>STOPPING=1</literal> (or termination). (see
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
- </para></listitem>
+ </para>
+
+ <xi:include href="version-info.xml" xpointer="v229"/></listitem>
</varlistentry>
<varlistentry>
<listitem><para>This option modifies <varname>RuntimeMaxSec=</varname> by increasing the maximum runtime by an
evenly distributed duration between 0 and the specified value (in seconds). If <varname>RuntimeMaxSec=</varname> is
unspecified, then this feature will be disabled.
- </para></listitem>
+ </para>
+
+ <xi:include href="version-info.xml" xpointer="v250"/></listitem>
</varlistentry>
<varlistentry>
<varlistentry>
<term><varname>Restart=</varname></term>
- <listitem><para>Configures whether the service shall be
- restarted when the service process exits, is killed, or a
- timeout is reached. The service process may be the main
- service process, but it may also be one of the processes
- specified with <varname>ExecStartPre=</varname>,
- <varname>ExecStartPost=</varname>,
- <varname>ExecStop=</varname>,
- <varname>ExecStopPost=</varname>, or
- <varname>ExecReload=</varname>. When the death of the process
- is a result of systemd operation (e.g. service stop or
- restart), the service will not be restarted. Timeouts include
- missing the watchdog "keep-alive ping" deadline and a service
- start, reload, and stop operation timeouts.</para>
-
- <para>Takes one of
- <option>no</option>,
- <option>on-success</option>,
- <option>on-failure</option>,
- <option>on-abnormal</option>,
- <option>on-watchdog</option>,
- <option>on-abort</option>, or
- <option>always</option>.
- If set to <option>no</option> (the default), the service will
- not be restarted. If set to <option>on-success</option>, it
- will be restarted only when the service process exits cleanly.
+ <listitem><para>Configures whether the service shall be restarted when the service process exits,
+ is killed, or a timeout is reached. The service process may be the main service process, but it may
+ also be one of the processes specified with <varname>ExecStartPre=</varname>,
+ <varname>ExecStartPost=</varname>, <varname>ExecStop=</varname>, <varname>ExecStopPost=</varname>,
+ or <varname>ExecReload=</varname>. When the death of the process is a result of systemd operation
+ (e.g. service stop or restart), the service will not be restarted. Timeouts include missing the watchdog
+ "keep-alive ping" deadline and a service start, reload, and stop operation timeouts.</para>
+
+ <para>Takes one of <option>no</option>, <option>on-success</option>, <option>on-failure</option>,
+ <option>on-abnormal</option>, <option>on-watchdog</option>, <option>on-abort</option>, or
+ <option>always</option>. If set to <option>no</option> (the default), the service will not be restarted.
+ If set to <option>on-success</option>, it will be restarted only when the service process exits cleanly.
In this context, a clean exit means any of the following:
<itemizedlist>
<listitem><simpara>exit code of 0;</simpara></listitem>
- <listitem><simpara>for types other than
- <varname>Type=oneshot</varname>, one of the signals
- <constant>SIGHUP</constant>,
- <constant>SIGINT</constant>,
- <constant>SIGTERM</constant>, or
- <constant>SIGPIPE</constant>;</simpara></listitem>
+ <listitem><simpara>for types other than <varname>Type=oneshot</varname>, one of the signals
+ <constant>SIGHUP</constant>, <constant>SIGINT</constant>,
+ <constant>SIGTERM</constant>, or <constant>SIGPIPE</constant>;
+ </simpara></listitem>
<listitem><simpara>exit statuses and signals specified in
<varname>SuccessExitStatus=</varname>.</simpara></listitem>
</itemizedlist>
- If set to
- <option>on-failure</option>, the service will be restarted
- when the process exits with a non-zero exit code, is
- terminated by a signal (including on core dump, but excluding
- the aforementioned four signals), when an operation (such as
- service reload) times out, and when the configured watchdog
- timeout is triggered. If set to <option>on-abnormal</option>,
- the service will be restarted when the process is terminated
- by a signal (including on core dump, excluding the
- aforementioned four signals), when an operation times out, or
- when the watchdog timeout is triggered. If set to
- <option>on-abort</option>, the service will be restarted only
- if the service process exits due to an uncaught signal not
- specified as a clean exit status. If set to
- <option>on-watchdog</option>, the service will be restarted
- only if the watchdog timeout for the service expires. If set
- to <option>always</option>, the service will be restarted
- regardless of whether it exited cleanly or not, got terminated
- abnormally by a signal, or hit a timeout.</para>
+ If set to <option>on-failure</option>, the service will be restarted when the process exits with
+ a non-zero exit code, is terminated by a signal (including on core dump, but excluding the aforementioned
+ four signals), when an operation (such as service reload) times out, and when the configured watchdog
+ timeout is triggered. If set to <option>on-abnormal</option>, the service will be restarted when
+ the process is terminated by a signal (including on core dump, excluding the aforementioned four signals),
+ when an operation times out, or when the watchdog timeout is triggered. If set to <option>on-abort</option>,
+ the service will be restarted only if the service process exits due to an uncaught signal not specified
+ as a clean exit status. If set to <option>on-watchdog</option>, the service will be restarted
+ only if the watchdog timeout for the service expires. If set to <option>always</option>, the service
+ will be restarted regardless of whether it exited cleanly or not, got terminated abnormally by
+ a signal, or hit a timeout. Note that <varname>Type=oneshot</varname> services will never be restarted
+ on a clean exit status, i.e. <option>always</option> and <option>on-success</option> are rejected
+ for them.</para>
<table>
<title>Exit causes and the effect of the <varname>Restart=</varname> settings</title>
<para>This option is useful in cases where a dependency can fail temporarily
but we don't want these temporary failures to make the dependent units fail.
When this option is set to <option>direct</option>, dependent units are not notified of these temporary failures.</para>
+
+ <xi:include href="version-info.xml" xpointer="v254"/>
</listitem>
</varlistentry>
</example>
<para>Note: <command>systemd-analyze exit-status</command> may be used to list exit statuses and
- translate between numerical status values and names.</para></listitem>
+ translate between numerical status values and names.</para>
+
+ <xi:include href="version-info.xml" xpointer="v189"/></listitem>
</varlistentry>
<varlistentry>
<listitem><para>Takes a list of exit status definitions that, when returned by the main service
process, will prevent automatic service restarts, regardless of the restart setting configured with
- <varname>Restart=</varname>. Exit status definitions can either be numeric exit codes or termination
- signal names, and are separated by spaces. Defaults to the empty list, so that, by default, no exit
- status is excluded from the configured restart logic. For example:
+ <varname>Restart=</varname>. Exit status definitions can be numeric termination statuses, termination
+ status names, or termination signal names, separated by spaces. Defaults to the empty list, so that,
+ by default, no exit status is excluded from the configured restart logic.
- <programlisting>RestartPreventExitStatus=1 6 SIGABRT</programlisting>
+ <example>
+ <title>A service with the <varname>RestartPreventExitStatus=</varname> setting</title>
- ensures that exit codes 1 and 6 and the termination signal <constant>SIGABRT</constant> will not
- result in automatic service restarting. This option may appear more than once, in which case the list
- of restart-preventing statuses is merged. If the empty string is assigned to this option, the list is
- reset and all prior assignments of this option will have no effect.</para>
+ <programlisting>RestartPreventExitStatus=TEMPFAIL 250 SIGKILL</programlisting>
+
+ <para>Exit status 75 (<constant>TEMPFAIL</constant>), 250, and the termination signal
+ <constant>SIGKILL</constant> will not result in automatic service restarting.</para>
+ </example>
+
+ This option may appear more than once, in which case the list of restart-preventing statuses is merged.
+ If the empty string is assigned to this option, the list is reset and all prior assignments of this
+ option will have no effect.</para>
<para>Note that this setting has no effect on processes configured via
<varname>ExecStartPre=</varname>, <varname>ExecStartPost=</varname>, <varname>ExecStop=</varname>,
<varname>ExecStopPost=</varname> or <varname>ExecReload=</varname>, but only on the main service
process, i.e. either the one invoked by <varname>ExecStart=</varname> or (depending on
<varname>Type=</varname>, <varname>PIDFile=</varname>, …) the otherwise configured main
- process.</para></listitem>
+ process.</para>
+
+ <xi:include href="version-info.xml" xpointer="v189"/></listitem>
</varlistentry>
<varlistentry>
<term><varname>RestartForceExitStatus=</varname></term>
- <listitem><para>Takes a list of exit status definitions that,
- when returned by the main service process, will force automatic
- service restarts, regardless of the restart setting configured
- with <varname>Restart=</varname>. The argument format is
- similar to
- <varname>RestartPreventExitStatus=</varname>.</para></listitem>
+
+ <listitem><para>Takes a list of exit status definitions that, when returned by the main service
+ process, will force automatic service restarts, regardless of the restart setting configured with
+ <varname>Restart=</varname>. The argument format is similar to <varname>RestartPreventExitStatus=</varname>.
+ </para>
+
+ <para>Note that for <varname>Type=oneshot</varname> services, a success exit status will prevent
+ them from auto-restarting, no matter whether the corresponding exit statuses are listed in this
+ option or not.</para>
+
+ <xi:include href="version-info.xml" xpointer="v215"/></listitem>
</varlistentry>
<varlistentry>
<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, 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
+ <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>
+ <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>
+
+ <para>Note that if the same socket unit is configured to be passed to multiple service units (via the
+ <varname>Sockets=</varname> setting, see below), and these services have different
+ <varname>NonBlocking=</varname> configurations, the precise state of <constant>O_NONBLOCK</constant>
+ depends on the order in which these services are invoked, and will possibly change after service code
+ already took possession of the socket file descriptor, simply because the
+ <constant>O_NONBLOCK</constant> state of a socket is shared by all file descriptors referencing
+ it. Hence it is essential that all services sharing the same socket use the same
+ <varname>NonBlocking=</varname> configuration, and do not change the flag in service code
+ either.</para></listitem>
</varlistentry>
<varlistentry>
<para>If this option is set to a non-zero value the <varname>$FDSTORE</varname> environment variable
will be set for processes invoked for this service. See
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
- details.</para></listitem>
+ details.</para>
+
+ <para>For further information on the file descriptor store see the <ulink
+ url="https://systemd.io/FILE_DESCRIPTOR_STORE">File Descriptor Store</ulink> overview.</para>
+
+ <xi:include href="version-info.xml" xpointer="v219"/></listitem>
</varlistentry>
<varlistentry>
file descriptor store pinned until the service manager exits.</para>
<para>Use <command>systemctl clean --what=fdstore …</command> to release the file descriptor store
- explicitly.</para></listitem>
+ explicitly.</para>
+
+ <xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>
<varlistentry>
socket unit with <varname>ListenUSBFunction=</varname>
configured. The contents of this file are written to the
<filename>ep0</filename> file after it is
- opened.</para></listitem>
+ opened.</para>
+
+ <xi:include href="version-info.xml" xpointer="v227"/></listitem>
</varlistentry>
<varlistentry>
<listitem><para>Configure the location of a file containing
USB FunctionFS strings. Behavior is similar to
<varname>USBFunctionDescriptors=</varname>
- above.</para></listitem>
+ above.</para>
+
+ <xi:include href="version-info.xml" xpointer="v227"/></listitem>
</varlistentry>
<varlistentry id='oom-policy'>
<constant>stop</constant> the event is logged but the unit is terminated cleanly by the service
manager. If set to <constant>kill</constant> and one of the unit's processes is killed by the OOM
killer the kernel is instructed to kill all remaining processes of the unit too, by setting the
- <filename>memory.oom.group</filename> attribute to <constant>1</constant>; also see <ulink
- url="https://docs.kernel.org/admin-guide/cgroup-v2.html">kernel documentation</ulink>.</para>
+ <filename>memory.oom.group</filename> attribute to <constant>1</constant>; also see kernel
+ page <ulink url="https://docs.kernel.org/admin-guide/cgroup-v2.html">Control Group v2</ulink>.
+ </para>
<para>Defaults to the setting <varname>DefaultOOMPolicy=</varname> in
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
<para>This setting also applies to
<citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
Similarly to the kernel OOM kills performed by the kernel, this setting determines the state of the
- unit after <command>systemd-oomd</command> kills a cgroup associated with it.</para></listitem>
+ unit after <command>systemd-oomd</command> kills a cgroup associated with it.</para>
+
+ <xi:include href="version-info.xml" xpointer="v243"/></listitem>
</varlistentry>
<varlistentry>
(due to running in a separate mount namespace, not having privileges, ...).</para>
<para>This setting can be specified multiple times, in which case all the specified paths are opened and the file descriptors passed to the service.
- If the empty string is assigned, the entire list of open files defined prior to this is reset.</para></listitem>
+ If the empty string is assigned, the entire list of open files defined prior to this is reset.</para>
+
+ <xi:include href="version-info.xml" xpointer="v253"/></listitem>
</varlistentry>
<varlistentry>
<listitem><para>Configures the UNIX process signal to send to the service's main process when asked
to reload the service's configuration. Defaults to <constant>SIGHUP</constant>. This option has no
effect unless <varname>Type=</varname><option>notify-reload</option> is used, see
- above.</para></listitem>
+ above.</para>
+
+ <xi:include href="version-info.xml" xpointer="v253"/></listitem>
</varlistentry>
</variablelist>
<row>
<entry><literal>:</literal></entry>
- <entry>If the executable path is prefixed with <literal>:</literal>, environment variable substitution (as described by the "Command Lines" section below) is not applied.</entry>
+ <entry>If the executable path is prefixed with <literal>:</literal>, environment variable substitution (as described below this table) is not applied.</entry>
</row>
<row>
systems using split <filename>/usr/bin/</filename> and <filename>/bin/</filename> directories, and their
<filename>sbin/</filename> counterparts on systems using split <filename>bin/</filename> and
<filename>sbin/</filename>. It is thus safe to use just the executable name in case of executables
- located in any of the "standard" directories, and an absolute path must be used in other cases. Using an
- absolute path is recommended to avoid ambiguity. Hint: this search path may be queried using
- <command>systemd-path search-binaries-default</command>.</para>
+ located in any of the "standard" directories, and an absolute path must be used in other cases.
+ Hint: this search path may be queried using <command>systemd-path search-binaries-default</command>.
+ </para>
<para>The command line accepts <literal>%</literal> specifiers as described in
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
Description=Simple notifying service
[Service]
-Type=notify
+Type=notify-reload
ExecStart=/usr/sbin/simple-notifying-service
[Install]
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details on how you can influence the way systemd terminates
the service.</para>
+
+ <para>To avoid code duplication, it is preferable to use
+ <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+ when possible, especially when other APIs provided by
+ <citerefentry><refentrytitle>libsystemd</refentrytitle><manvolnum>3</manvolnum></citerefentry> are
+ also used, but note that the notification protocol is very simple and guaranteed to be stable as per
+ the <ulink url="https://systemd.io/PORTABILITY_AND_STABILITY/">Interface Portability and Stability
+ Promise</ulink>, so it can be reimplemented by services with no external dependencies. For a
+ self-contained example, see
+ <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
</example>
</refsect1>
<refsect1>
<title>See Also</title>
- <para>
- <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>
- </para>
+ <para><simplelist type="inline">
+ <member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
+ </simplelist></para>
</refsect1>
</refentry>
projects / thirdparty / systemd.git / blobdiff