<refnamediv>
<refname>systemd.service</refname>
- <refpurpose>systemd service configuration files</refpurpose>
+ <refpurpose>Service unit configuration</refpurpose>
</refnamediv>
<refsynopsisdiv>
<para>Additional options are listed in
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
which define the execution environment the commands
- are executed in.</para>
+ are executed in, and in
+ <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ which define the way the processes of the service are
+ terminated.</para>
<para>Unless <varname>DefaultDependencies=</varname>
is set to <option>false</option>, service units will
<filename>.service</filename> suffix removed) and
dynamically creates a service unit from that
script. This is useful for compatibility with
- SysV.</para>
+ SysV. Note that this compatibility is quite
+ comprehensive but not 100%. For details about the
+ incompatibilities see the <ulink
+ url="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
+ with SysV</ulink> document.
+ </para>
</refsect1>
<refsect1>
supervises. A number of options that may be used in
this section are shared with other unit types. These
options are documented in
- <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ and
+ <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
options specific to the <literal>[Service]</literal>
section of service units are the following:</para>
complete and all communication
channels set up. The child continues
to run as the main daemon
- process. This is the behaviour of
+ process. This is the behavior of
traditional UNIX daemons. If this
setting is used, it is recommended to
also use the
soon as the parent process
exits.</para>
- <para>Behaviour of
+ <para>Behavior of
<option>oneshot</option> is similar
to <option>simple</option>, however
it is expected that the process has to
is particularly useful for this type
of service.</para>
- <para>Behaviour of
+ <para>Behavior of
<option>dbus</option> is similar to
<option>simple</option>, however it is
expected that the daemon acquires a
<varname>BusName=</varname> is
specified.</para>
- <para>Behaviour of
+ <para>Behavior of
<option>notify</option> is similar to
<option>simple</option>, however it is
expected that the daemon sends a
not set, it will be implicitly set to
<option>main</option>.</para>
- <para>Behaviour of
+ <para>Behavior of
<option>idle</option> is very similar
to <option>simple</option>, however
- actual execution of a the service
+ actual execution of the service
binary is delayed until all jobs are
dispatched. This may be used to avoid
interleaving of output of shell
<listitem><para>Takes a boolean value
that specifies whether systemd should
try to guess the main PID of a service
- should if it cannot be determined
+ if it cannot be determined
reliably. This option is ignored
unless <option>Type=forking</option>
is set and <option>PIDFile=</option>
<term><varname>BusName=</varname></term>
<listitem><para>Takes a D-Bus bus
- name, where this service is reachable
+ name, that this service is reachable
as. This option is mandatory for
services where
<varname>Type=</varname> is set to
<varlistentry>
<term><varname>ExecStart=</varname></term>
- <listitem><para>Takes a command line
- that is executed when this service
- shall be started up. The first token
- of the command line must be an
- absolute file name, then followed by
- arguments for the process. It is
- mandatory to set this option for all
- services. This option may not be
- specified more than once, except when
- <varname>Type=oneshot</varname> is
- used in which case more than one
- <varname>ExecStart=</varname> line is
- accepted which are then invoked one by
- one, sequentially in the order they
- appear in the unit file.</para>
+ <listitem><para>Commands with their
+ arguments that are executed when this
+ service is started.
+ </para>
- <para>Optionally, if the absolute 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
- first token 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 both
- <literal>-</literal> and
- <literal>@</literal> are used for the
- same command the former must precede
- the latter. Unless
+ <para>When
+ <varname>Type=oneshot</varname> is
+ used, more than one command may be
+ specified. Multiple command lines may
+ be concatenated in a single directive,
+ by separating them with semicolons
+ (these semicolons must be passed as
+ separate words). Alternatively, this
+ directive may be specified more than
+ once with the same effect. However,
+ the latter syntax is not recommended
+ for compatibility with parsers
+ suitable for XDG
+ <filename>.desktop</filename> files.
+ The commands are invoked one by one
+ sequentially in the order they appear
+ in the unit file. When
+ <varname>Type</varname> is not
+ <option>oneshot</option>, only one
+ command may be given. Lone semicolons
+ may be escaped as
+ '<literal>\;</literal>'. If the empty
+ string is assigned to this option the
+ list of commands to start is reset,
+ prior assignments of this option will
+ have no effect.</para>
+
+ <para>Unless
<varname>Type=forking</varname> is
set, the process started via this
command line will be considered the
- main process of the daemon. The
- command line accepts % specifiers as
+ main process of the daemon.</para>
+
+ <para>The command line accepts
+ '<literal>%</literal>' specifiers as
described in
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note
+ that the first argument of the command
+ line (i.e. the program to execute) may
+ not include specifiers.</para>
<para>On top of that basic environment
variable substitution is
supported. Use
<literal>${FOO}</literal> as part of a
- word, or as word of its own on the
+ word, or as a word of its own on the
command line, in which case it will be
replaced by the value of the
environment variable including all
argument (i.e. the program to execute)
may not be a variable, and must be a
literal and absolute path
- name.</para></listitem>
+ name.</para>
+
+ <para>Optionally, if the absolute 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 file name 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 both
+ '<literal>-</literal>' and
+ '<literal>@</literal>' are used they
+ can appear in either order.</para>
+
+ <para>Note that this setting does not
+ directly support shell command
+ lines. If shell command lines are to
+ be used they need to be passed
+ explicitly to a shell implementation
+ of some kind. Example:
+ <literal>ExecStart=/bin/sh -c 'dmesg | tac'</literal></para>
+
+ <para>For services run by a user
+ instance of systemd the special
+ environment variable
+ <literal>MANAGERPID</literal> is set
+ to the PID of the systemd
+ instance.</para>
+ </listitem>
</varlistentry>
<varlistentry>
<term><varname>ExecStartPre=</varname></term>
<term><varname>ExecStartPost=</varname></term>
<listitem><para>Additional commands
- that are executed before (resp. after)
+ that are executed before or after
the command in
- <varname>ExecStart=</varname>. Multiple
- command lines may be concatenated in a
- single directive, by separating them
- by semicolons (these semicolons must
- be passed as separate words). In that
- case, the commands are executed one
- after the other,
- serially. Alternatively, these
- directives may be specified more than
- once with the same effect. However,
- the latter syntax is not recommended
- for compatibility with parsers
- suitable for XDG
- <filename>.desktop</filename> files.
- Use of these settings is
- optional. Specifier and environment
- variable substitution is
- supported.</para></listitem>
+ <varname>ExecStart=</varname>, respectively.
+ Syntax is the same as for
+ <varname>ExecStart=</varname>, except
+ that multiple command lines are allowed
+ and the commands are executed one
+ after the other, serially.</para>
+ </listitem>
</varlistentry>
<varlistentry>
trigger a configuration reload in the
service. This argument takes multiple
command lines, following the same
- scheme as pointed out for
- <varname>ExecStartPre=</varname>
+ scheme as described for
+ <varname>ExecStart=</varname>
above. Use of this setting is
optional. Specifier and environment
variable substitution is supported
here following the same scheme as for
<varname>ExecStart=</varname>. One
- special environment variable is set:
- if known <literal>$MAINPID</literal> is
- set to the main process of the
- daemon, and may be used for command
- lines like the following:
- <command>/bin/kill -HUP
+ additional special environment
+ variables is set: if known
+ <literal>$MAINPID</literal> is set to
+ the main process of the daemon, and
+ may be used for command lines like the
+ following: <command>/bin/kill -HUP
$MAINPID</command>.</para></listitem>
</varlistentry>
stop the service started via
<varname>ExecStart=</varname>. This
argument takes multiple command lines,
- following the same scheme as pointed
- out for
- <varname>ExecStartPre=</varname>
+ following the same scheme as described
+ for <varname>ExecStart=</varname>
above. Use of this setting is
optional. All processes remaining for
a service after the commands
configured in this option are run are
terminated according to the
<varname>KillMode=</varname> setting
- (see below). If this option is not
- specified the process is terminated
- right-away when service stop is
- requested. Specifier and environment
- variable substitution is supported
- (including
+ (see
+ <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If
+ this option is not specified the
+ process is terminated right-away when
+ service stop is requested. Specifier
+ and environment variable substitution
+ is supported (including
<literal>$MAINPID</literal>, see
above).</para></listitem>
</varlistentry>
configured in
<varname>ExecStop=</varname>. This
argument takes multiple command lines,
- following the same scheme as pointed
- out for
- <varname>ExecStartPre</varname>. Use
+ following the same scheme as described
+ for <varname>ExecStart</varname>. Use
of these settings is
optional. Specifier and environment
variable substitution is
</varlistentry>
<varlistentry>
- <term><varname>TimeoutSec=</varname></term>
+ <term><varname>TimeoutStartSec=</varname></term>
<listitem><para>Configures the time to
- wait for start-up and stop. If a
+ wait for start-up. If a
daemon service does not signal
start-up completion within the
- configured time the service will be
+ configured time, the service will be
considered failed and be shut down
- again. If a service is asked to stop
- but does not terminate in the
- specified time it will be terminated
+ again.
+ Takes a unit-less value in seconds, or a
+ time span value such as "5min
+ 20s". Pass 0 to disable the timeout
+ logic. Defaults to 90s, except when
+ <varname>Type=oneshot</varname> is
+ used in which case the timeout
+ is disabled by default.
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>TimeoutStopSec=</varname></term>
+ <listitem><para>Configures the time to
+ wait for stop. If a service is asked
+ to stop but does not terminate in the
+ specified time, it will be terminated
forcibly via SIGTERM, and after
another delay of this time with
- SIGKILL. (See
+ SIGKILL (See
<varname>KillMode=</varname>
- below.) Takes a unit-less value in seconds, or a
+ in <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+ Takes a unit-less value in seconds, or a
time span value such as "5min
20s". Pass 0 to disable the timeout
- logic. Defaults to
- 90s.</para></listitem>
+ logic. Defaults to 90s.
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>TimeoutSec=</varname></term>
+ <listitem><para>A shorthand for configuring
+ both <varname>TimeoutStartSec=</varname>
+ and <varname>TimeoutStopSec=</varname>
+ to the specified value.
+ </para></listitem>
</varlistentry>
<varlistentry>
is activated when the start-up is
completed. The service must call
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
- regularly with "WATCHDOG=1". If the
- time between two such calls is larger
- than the configured time then the
- service is placed in a failure
- state. By setting
- <varname>Restart=</varname>
- to <option>on-failure</option> or
+ regularly with "WATCHDOG=1" (i.e. the
+ "keep-alive ping"). If the time
+ between two such calls is larger than
+ the configured time then the service
+ is placed in a failure state. By
+ setting <varname>Restart=</varname> to
+ <option>on-failure</option> or
<option>always</option> the service
will be automatically restarted. The
time configured here will be passed to
the executed service process in the
<varname>WATCHDOG_USEC=</varname>
- environment variable. If
+ environment variable. This allows
+ daemons to automatically enable the
+ keep-alive pinging logic if watchdog
+ support is enabled for the service. If
this option is used
<varname>NotifyAccess=</varname> (see
below) should be set to open access to
the notification socket provided by
systemd. If
- <varname>NotifyAccess=</varname> is not
- set, it will be implicitly set to
+ <varname>NotifyAccess=</varname> is
+ not set, it will be implicitly set to
<option>main</option>. Defaults to 0,
which disables this
feature.</para></listitem>
0. If set to
<option>on-failure</option> it will be
restarted only when it exited with an
- exit code not equalling 0, when
- terminated by a signal, when an
- operation times out or when the
+ exit code not equaling 0, when
+ terminated by a signal (including on
+ core dump), when an operation (such as
+ service reload) times out or when the
configured watchdog timeout is
triggered. If set to
<option>on-abort</option> it will be
restarted only if it exits due to
- reception of an uncaught signal. If
- set to <option>always</option> the
- service will be restarted regardless
- whether it exited cleanly or not,
- got terminated abnormally by a
- signal or hit a timeout.</para></listitem>
+ reception of an uncaught signal
+ (including on core dump). If set to
+ <option>always</option> the service
+ will be restarted regardless whether
+ it exited cleanly or not, got
+ terminated abnormally by a signal or
+ hit a timeout.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>SuccessExitStatus=</varname></term>
+ <listitem><para>Takes a list of exit
+ status definitions that when returned
+ by the main service process will be
+ considered successful termination, in
+ addition to the normal successful exit
+ code 0 and the signals SIGHUP, SIGINT,
+ SIGTERM and SIGPIPE. Exit status
+ definitions can either be numeric exit
+ codes or termination signal names, and
+ are separated by spaces. Example:
+ "<literal>SuccessExitStatus=1 2 8
+ SIGKILL</literal>", ensures that exit
+ codes 1, 2, 8 and the termination
+ signal SIGKILL are considered clean
+ service terminations. 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>
+ <term><varname>RestartPreventExitStatus=</varname></term>
+ <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. Example:
+ "<literal>RestartPreventExitStatus=1 6
+ SIGABRT</literal>", ensures that exit
+ codes 1 and 6 and the termination
+ signal SIGABRT 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, all prior assignments
+ of this option will have no
+ effect.</para></listitem>
</varlistentry>
<varlistentry>
false.</para></listitem>
</varlistentry>
- <varlistentry>
- <term><varname>SysVStartPriority=</varname></term>
- <listitem><para>Set the SysV start
- priority to use to order this service
- in relation to SysV services lacking
- LSB headers. This option is only
- necessary to fix ordering in relation
- to legacy SysV services, that have no
- ordering information encoded in the
- script headers. As such it should only
- be used as temporary compatibility
- option, and not be used in new unit
- files. Almost always it is a better
- choice to add explicit ordering
- directives via
- <varname>After=</varname> or
- <varname>Before=</varname>,
- instead. For more details see
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
- used, pass an integer value in the
- range 0-99.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><varname>KillMode=</varname></term>
- <listitem><para>Specifies how
- processes of this service shall be
- killed. One of
- <option>control-group</option>,
- <option>process</option>,
- <option>none</option>.</para>
-
- <para>If set to
- <option>control-group</option> all
- remaining processes in the control
- group of this service will be
- terminated on service stop, after the
- stop command (as configured with
- <varname>ExecStop=</varname>) is
- executed. If set to
- <option>process</option> only the main
- process itself is killed. If set to
- <option>none</option> no process is
- killed. In this case only the stop
- command will be executed on service
- stop, but no process be killed
- otherwise. Processes remaining alive
- after stop are left in their control
- group and the control group continues
- to exist after stop unless it is
- empty. Defaults to
- <option>control-group</option>.</para>
-
- <para>Processes will first be
- terminated via SIGTERM (unless the
- signal to send is changed via
- <varname>KillSignal=</varname>). If
- then after a delay (configured via the
- <varname>TimeoutSec=</varname> option)
- processes still remain, the
- termination request is repeated with
- the SIGKILL signal (unless this is
- disabled via the
- <varname>SendSIGKILL=</varname>
- option). See
- <citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>
- for more
- information.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><varname>KillSignal=</varname></term>
- <listitem><para>Specifies which signal
- to use when killing a
- service. Defaults to SIGTERM.
- </para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><varname>SendSIGKILL=</varname></term>
- <listitem><para>Specifies whether to
- send SIGKILL to remaining processes
- after a timeout, if the normal
- shutdown procedure left processes of
- the service around. Takes a boolean
- value. Defaults to "yes".
- </para></listitem>
- </varlistentry>
-
<varlistentry>
<term><varname>NonBlocking=</varname></term>
<listitem><para>Set O_NONBLOCK flag
same time. Also note that a different
service may be activated on incoming
traffic than inherits the sockets. Or
- in other words: The
+ in other words: the
<varname>Service=</varname> setting of
<filename>.socket</filename> units
- doesn't have to match the inverse of the
- <varname>Sockets=</varname> setting of
- the <filename>.service</filename> it
- refers to.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><varname>FsckPassNo=</varname></term>
- <listitem><para>Set the fsck passno
- priority to use to order this service
- in relation to other file system
- checking services. This option is only
- necessary to fix ordering in relation
- to fsck jobs automatically created for
- all <filename>/etc/fstab</filename>
- entries with a value in the fs_passno
- column > 0. As such it should only be
- used as option for fsck
- services. Almost always it is a better
- choice to add explicit ordering
- directives via
- <varname>After=</varname> or
- <varname>Before=</varname>,
- instead. For more details see
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
- used, pass an integer value in the
- same range as
- <filename>/etc/fstab</filename>'s
- fs_passno column. See
- <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- for details.</para></listitem>
+ doesn't have to match the inverse of
+ the <varname>Sockets=</varname>
+ setting of the
+ <filename>.service</filename> it
+ refers to.</para>
+
+ <para>This option may appear more than
+ once, in which case the list of socket
+ units is merged. If the empty string
+ is assigned to this option the list of
+ sockets is reset, all prior uses of
+ this setting will have no
+ effect.</para></listitem>
</varlistentry>
<varlistentry>
are allowed (defaults to 5). These
configuration options are particularly
useful in conjunction with
- <varname>Restart=</varname>.</para></listitem>
+ <varname>Restart=</varname>, however
+ apply to all kinds of starts
+ (including manual), not just those
+ triggered by the
+ <varname>Restart=</varname> logic.
+ Note that units which are configured
+ for <varname>Restart=</varname> and
+ which reach the start limit are not
+ attempted to be restarted anymore,
+ however they may still be restarted
+ manually at a later point from which
+ point on the restart logic is again
+ activated. Note that
+ <command>systemctl
+ reset-failed</command> will cause the
+ restart rate counter for a service to
+ be flushed, which is useful if the
+ administrator wants to manually start
+ a service and the start limit
+ interferes with
+ that.</para></listitem>
</varlistentry>
<varlistentry>
<option>none</option>.</para></listitem>
</varlistentry>
+ </variablelist>
+
+ <para>Check
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ and
+ <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for more settings.</para>
+
+ </refsect1>
+
+ <refsect1>
+ <title>Compatibility Options</title>
+
+ <para>The following options are also available in the
+ <literal>[Service]</literal> section, but exist purely
+ for compatibility reasons and should not be used in
+ newly written service files.</para>
+
+ <variablelist>
<varlistentry>
- <term><varname>FsckPassNo=</varname></term>
+ <term><varname>SysVStartPriority=</varname></term>
+ <listitem><para>Set the SysV start
+ priority to use to order this service
+ in relation to SysV services lacking
+ LSB headers. This option is only
+ necessary to fix ordering in relation
+ to legacy SysV services, that have no
+ ordering information encoded in the
+ script headers. As such it should only
+ be used as temporary compatibility
+ option, and not be used in new unit
+ files. Almost always it is a better
+ choice to add explicit ordering
+ directives via
+ <varname>After=</varname> or
+ <varname>Before=</varname>,
+ instead. For more details see
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
+ used, pass an integer value in the
+ range 0-99.</para></listitem>
+ </varlistentry>
- <listitem><para>If this is an file
- system checking service specify the
- pass number. This should not be used
- for normal services.</para></listitem>
+ <varlistentry>
+ <term><varname>FsckPassNo=</varname></term>
+ <listitem><para>Set the fsck passno
+ priority to use to order this service
+ in relation to other file system
+ checking services. This option is only
+ necessary to fix ordering in relation
+ to fsck jobs automatically created for
+ all <filename>/etc/fstab</filename>
+ entries with a value in the fs_passno
+ column > 0. As such it should only be
+ used as option for fsck
+ services. Almost always it is a better
+ choice to add explicit ordering
+ directives via
+ <varname>After=</varname> or
+ <varname>Before=</varname>,
+ instead. For more details see
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
+ used, pass an integer value in the
+ same range as
+ <filename>/etc/fstab</filename>'s
+ fs_passno column. See
+ <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details.</para></listitem>
</varlistentry>
</variablelist>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
</para>
</refsect1>
~ianmdlvl / elogind.git / blobdiff