2010-06-22 04:42:10 +04:00
<?xml version='1.0'?> <!-- * - nxml - * -->
< !DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
This file is part of systemd.
Copyright 2010 Lennart Poettering
systemd is free software; you can redistribute it and/or modify it
2012-04-12 02:20:58 +04:00
under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation; either version 2.1 of the License, or
2010-06-22 04:42:10 +04:00
(at your option) any later version.
systemd is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
2012-04-12 02:20:58 +04:00
Lesser General Public License for more details.
2010-06-22 04:42:10 +04:00
2012-04-12 02:20:58 +04:00
You should have received a copy of the GNU Lesser General Public License
2010-06-22 04:42:10 +04:00
along with systemd; If not, see <http: / / w w w . g n u . o r g / l i c e n s e s /> .
-->
2010-07-03 21:54:00 +04:00
<refentry id= "daemon" >
2010-06-22 04:42:10 +04:00
<refentryinfo >
<title > daemon</title>
<productname > systemd</productname>
<authorgroup >
<author >
<contrib > Developer</contrib>
<firstname > Lennart</firstname>
<surname > Poettering</surname>
<email > lennart@poettering.net</email>
</author>
</authorgroup>
</refentryinfo>
<refmeta >
<refentrytitle > daemon</refentrytitle>
<manvolnum > 7</manvolnum>
</refmeta>
<refnamediv >
<refname > daemon</refname>
2012-07-16 20:08:25 +04:00
<refpurpose > Writing and packaging system daemons</refpurpose>
2010-06-22 04:42:10 +04:00
</refnamediv>
<refsect1 >
<title > Description</title>
<para > A daemon is a service process that runs in the
background and supervises the system or provides
functionality to other processes. Traditionally,
daemons are implemented following a scheme originating
in SysV Unix. Modern daemons should follow a simpler
2010-07-03 21:54:00 +04:00
yet more powerful scheme (here called "new-style"
daemons), as implemented by
2010-07-06 05:20:49 +04:00
<citerefentry > <refentrytitle > systemd</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> . This
manual page covers both schemes, and in
particular includes recommendations for daemons that
shall be included in the systemd init system.</para>
2010-06-22 04:42:10 +04:00
<refsect2 >
<title > SysV Daemons</title>
<para > When a traditional SysV daemon
starts, it should execute the following steps
as part of the initialization. Note that these
2010-07-03 21:54:00 +04:00
steps are unnecessary for new-style daemons (see below),
2010-06-24 19:25:16 +04:00
and should only be implemented if compatibility
2010-06-22 04:42:10 +04:00
with SysV is essential.</para>
<orderedlist >
<listitem > <para > Close all open file
2014-02-15 07:00:06 +04:00
descriptors except stdin, stdout,
stderr (i.e. the first three file
2010-06-22 04:42:10 +04:00
descriptors 0, 1, 2). This ensures
that no accidentally passed file
descriptor stays around in the daemon
2013-07-02 07:44:04 +04:00
process. On Linux, this is best
2010-06-22 04:42:10 +04:00
implemented by iterating through
<filename > /proc/self/fd</filename> ,
with a fallback of iterating from file
descriptor 3 to the value returned by
2010-07-03 21:54:00 +04:00
<function > getrlimit()</function> for
2010-06-22 04:42:10 +04:00
RLIMIT_NOFILE.</para> </listitem>
<listitem > <para > Reset all signal
handlers to their default. This is
best done by iterating through the
available signals up to the limit of
_NSIG and resetting them to
2013-06-29 20:09:14 +04:00
<constant > SIG_DFL</constant> .</para> </listitem>
2010-06-22 04:42:10 +04:00
<listitem > <para > Reset the signal mask
2010-07-03 21:54:00 +04:00
using
<function > sigprocmask()</function> .</para> </listitem>
2010-06-22 04:42:10 +04:00
2010-07-03 21:54:00 +04:00
<listitem > <para > Sanitize the
environment block, removing or
resetting environment variables that
might negatively impact daemon
runtime.</para> </listitem>
<listitem > <para > Call <function > fork()</function> ,
2010-06-22 04:42:10 +04:00
to create a background
process.</para> </listitem>
<listitem > <para > In the child, call
2010-07-03 21:54:00 +04:00
<function > setsid()</function> to
detach from any terminal and create an
independent session.</para> </listitem>
2010-06-22 04:42:10 +04:00
<listitem > <para > In the child, call
2010-07-03 21:54:00 +04:00
<function > fork()</function> again, to
2013-07-02 07:44:04 +04:00
ensure that the daemon can never re-acquire
2010-07-03 21:54:00 +04:00
a terminal again.</para> </listitem>
2010-06-22 04:42:10 +04:00
2010-07-03 21:54:00 +04:00
<listitem > <para > Call <function > exit()</function> in the
2010-06-22 04:42:10 +04:00
first child, so that only the second
child (the actual daemon process)
stays around. This ensures that the
2012-11-29 23:06:57 +04:00
daemon process is re-parented to
2010-06-22 04:42:10 +04:00
init/PID 1, as all daemons should
be.</para> </listitem>
<listitem > <para > In the daemon process,
connect <filename > /dev/null</filename>
2014-02-15 07:00:06 +04:00
to standard input, output, and error.
</para> </listitem>
2010-06-22 04:42:10 +04:00
<listitem > <para > In the daemon process,
reset the umask to 0, so that the file
2010-07-03 21:54:00 +04:00
modes passed to <function > open()</function> , <function > mkdir()</function> and
2010-06-22 04:42:10 +04:00
suchlike directly control the access
mode of the created files and
directories.</para> </listitem>
<listitem > <para > In the daemon process,
change the current directory to the
root directory (/), in order to avoid
that the daemon involuntarily
blocks mount points from being
unmounted.</para> </listitem>
2010-07-03 21:54:00 +04:00
<listitem > <para > In the daemon process,
write the daemon PID (as returned by
<function > getpid()</function> ) to a
PID file, for example
2014-02-26 05:11:04 +04:00
<filename > /run/foobar.pid</filename>
2013-07-02 07:44:04 +04:00
(for a hypothetical daemon "foobar")
2010-07-03 21:54:00 +04:00
to ensure that the daemon cannot be
started more than once. This must be
implemented in race-free fashion so
that the PID file is only updated when
2013-07-02 07:44:04 +04:00
it is verified at the same time that
2010-07-03 21:54:00 +04:00
the PID previously stored in the PID
file no longer exists or belongs to a
2013-07-02 07:44:04 +04:00
foreign process. Commonly, some kind of
2010-07-03 21:54:00 +04:00
file locking is employed to implement
this logic.</para> </listitem>
2010-06-22 04:42:10 +04:00
<listitem > <para > In the daemon process,
drop privileges, if possible and
applicable.</para> </listitem>
<listitem > <para > From the daemon
2013-07-02 07:44:04 +04:00
process, notify the original process
2010-06-22 04:42:10 +04:00
started that initialization is
complete. This can be implemented via
an unnamed pipe or similar
communication channel that is created
2010-07-03 21:54:00 +04:00
before the first
<function > fork()</function> and hence
available in both the original and the
daemon process.</para> </listitem>
2010-06-22 04:42:10 +04:00
2010-07-03 21:54:00 +04:00
<listitem > <para > Call
<function > exit()</function> in the
2010-06-22 04:42:10 +04:00
original process. The process that
invoked the daemon must be able to
2012-09-04 21:24:16 +04:00
rely on that this
2010-07-03 21:54:00 +04:00
<function > exit()</function> happens
after initialization is complete and
all external communication channels
2012-09-04 21:24:16 +04:00
are established and
2010-06-22 04:42:10 +04:00
accessible.</para> </listitem>
</orderedlist>
2010-07-03 21:54:00 +04:00
<para > The BSD <function > daemon()</function> function should not be
used, as it implements only a subset of these steps.</para>
2010-06-22 04:42:10 +04:00
<para > A daemon that needs to provide
compatibility with SysV systems should
implement the scheme pointed out
above. However, it is recommended to make this
2012-09-04 21:24:16 +04:00
behavior optional and configurable via a
2013-07-02 07:44:04 +04:00
command line argument to ease debugging as
2010-06-22 04:42:10 +04:00
well as to simplify integration into systems
using systemd.</para>
</refsect2>
<refsect2 >
<title > New-Style Daemons</title>
<para > Modern services for Linux should be
implemented as new-style daemons. This makes it
easier to supervise and control them at
runtime and simplifies their
implementation.</para>
2013-07-02 07:44:04 +04:00
<para > For developing a new-style daemon, none
2010-06-22 04:42:10 +04:00
of the initialization steps recommended for
SysV daemons need to be implemented. New-style
init systems such as systemd make all of them
redundant. Moreover, since some of these steps
interfere with process monitoring, file
descriptor passing and other functionality of
2013-07-02 07:44:04 +04:00
the init system, it is recommended not to
2010-06-22 04:42:10 +04:00
execute them when run as new-style
service.</para>
2010-07-03 21:54:00 +04:00
<para > Note that new-style init systems
2014-02-15 07:00:06 +04:00
guarantee execution of daemon processes in a
clean process context: it is guaranteed that
2010-07-03 21:54:00 +04:00
the environment block is sanitized, that the
signal handlers and mask is reset and that no
left-over file descriptors are passed. Daemons
2014-02-15 07:00:06 +04:00
will be executed in their own session, with
standard input/output/error connected to
2010-07-03 21:54:00 +04:00
<filename > /dev/null</filename> unless
2014-02-15 07:00:06 +04:00
otherwise configured. The umask is reset.
</para>
2010-07-03 21:54:00 +04:00
2010-06-22 04:42:10 +04:00
<para > It is recommended for new-style daemons
to implement the following:</para>
<orderedlist >
2013-06-29 20:09:14 +04:00
<listitem > <para > If <constant > SIGTERM</constant> is
2010-06-22 04:42:10 +04:00
received, shut down the daemon and
exit cleanly.</para> </listitem>
2013-06-29 20:09:14 +04:00
<listitem > <para > If <constant > SIGHUP</constant> is received,
2010-06-22 04:42:10 +04:00
reload the configuration files, if
this applies.</para> </listitem>
<listitem > <para > Provide a correct exit
code from the main daemon process, as
this is used by the init system to
detect service errors and problems. It
is recommended to follow the exit code
2010-07-03 21:54:00 +04:00
scheme as defined in the <ulink
url="http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB
recommendations for SysV init
scripts</ulink> .</para> </listitem>
2010-06-22 04:42:10 +04:00
<listitem > <para > If possible and
2013-07-02 07:44:04 +04:00
applicable, expose the daemon's control
2010-06-22 04:42:10 +04:00
interface via the D-Bus IPC system and
grab a bus name as last step of
initialization.</para> </listitem>
2010-07-06 05:20:49 +04:00
<listitem > <para > For integration in
systemd, provide a
<filename > .service</filename> unit
file that carries information about
starting, stopping and otherwise
maintaining the daemon. See
<citerefentry > <refentrytitle > systemd.service</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
for details.</para> </listitem>
<listitem > <para > As much as possible,
2012-09-04 21:24:16 +04:00
rely on the init system's
2010-07-06 05:20:49 +04:00
functionality to limit the access of
the daemon to files, services and
2013-07-02 07:44:04 +04:00
other resources, i.e. in the case of
2010-07-06 05:20:49 +04:00
systemd, rely on systemd's resource
limit control instead of implementing
your own, rely on systemd's privilege
dropping code instead of implementing
it in the daemon, and similar. See
<citerefentry > <refentrytitle > systemd.exec</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
for the available
controls.</para> </listitem>
2010-06-22 04:42:10 +04:00
<listitem > <para > If D-Bus is used, make
2013-07-02 07:44:04 +04:00
your daemon bus-activatable by
2010-06-22 04:42:10 +04:00
supplying a D-Bus service activation
configuration file. This has multiple
advantages: your daemon may be started
lazily on-demand; it may be started in
parallel to other daemons requiring it
-- which maximizes parallelization and
boot-up speed; your daemon can be
2013-07-02 07:44:04 +04:00
restarted on failure without losing
2010-06-22 04:42:10 +04:00
any bus requests, as the bus queues
2010-07-03 21:54:00 +04:00
requests for activatable services. See
below for details.</para> </listitem>
2010-06-22 04:42:10 +04:00
<listitem > <para > If your daemon
provides services to other local
processes or remote clients via a
socket, it should be made
socket-activatable following the
scheme pointed out below. Like D-Bus
2013-07-02 07:44:04 +04:00
activation, this enables on-demand
2010-06-22 04:42:10 +04:00
starting of services as well as it
2010-06-24 19:25:16 +04:00
allows improved parallelization of
2010-06-22 04:42:10 +04:00
service start-up. Also, for state-less
2013-07-02 07:44:04 +04:00
protocols (such as syslog, DNS), a
2010-06-22 04:42:10 +04:00
daemon implementing socket-based
activation can be restarted without
2010-07-03 21:54:00 +04:00
losing a single request. See below for
details.</para> </listitem>
2010-06-22 04:42:10 +04:00
2013-07-02 07:44:04 +04:00
<listitem > <para > If applicable, a daemon
2010-06-22 04:42:10 +04:00
should notify the init system about
2010-07-03 21:54:00 +04:00
startup completion or status updates
via the
<citerefentry > <refentrytitle > sd_notify</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry>
2010-06-22 04:42:10 +04:00
interface.</para> </listitem>
<listitem > <para > Instead of using the
2010-07-03 21:54:00 +04:00
<function > syslog()</function> call to log directly to the
2011-08-31 00:42:49 +04:00
system syslog service, a new-style daemon may
2014-02-15 07:00:06 +04:00
choose to simply log to standard error via
2010-07-03 21:54:00 +04:00
<function > fprintf()</function> , which is then forwarded to
2010-06-22 04:42:10 +04:00
syslog by the init system. If log
2013-07-02 07:44:04 +04:00
priorities are necessary, these can be
2010-06-22 04:42:10 +04:00
encoded by prefixing individual log
lines with strings like "< 4> "
(for log priority 4 "WARNING" in the
syslog priority scheme), following a
similar style as the Linux kernel's
2010-07-03 21:54:00 +04:00
<function > printk()</function> priority system. In fact,
using this style of logging also
enables the init system to optionally
direct all application logging to the
kernel log buffer (kmsg), as
accessible via
<citerefentry > <refentrytitle > dmesg</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> . This
kind of logging may be enabled by
setting
<varname > StandardError=syslog</varname>
2013-07-02 07:44:04 +04:00
in the service unit file. For details,
2010-07-03 21:54:00 +04:00
see
2012-07-13 03:50:05 +04:00
<citerefentry > <refentrytitle > sd-daemon</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry>
2010-07-03 21:54:00 +04:00
and
<citerefentry > <refentrytitle > systemd.exec</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> .</para> </listitem>
2010-06-22 04:42:10 +04:00
</orderedlist>
2010-07-03 21:54:00 +04:00
<para > These recommendations are similar but
not identical to the <ulink
url="http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPSystemStartup/Articles/LaunchOnDemandDaemons.html#//apple_ref/doc/uid/TP40001762-104738">Apple
MacOS X Daemon Requirements</ulink> .</para>
2010-06-22 04:42:10 +04:00
</refsect2>
2010-07-06 05:20:49 +04:00
</refsect1>
<refsect1 >
<title > Activation</title>
<para > New-style init systems provide multiple
additional mechanisms to activate services, as
detailed below. It is common that services are
configured to be activated via more than one mechanism
at the same time. An example for systemd:
<filename > bluetoothd.service</filename> might get
activated either when Bluetooth hardware is plugged
in, or when an application accesses its programming
interfaces via D-Bus. Or, a print server daemon might
get activated when traffic arrives at an IPP port, or
when a printer is plugged in, or when a file is queued
in the printer spool directory. Even for services that
are intended to be started on system bootup
2013-07-02 07:44:04 +04:00
unconditionally, it is a good idea to implement some of
2010-07-06 05:20:49 +04:00
the various activation schemes outlined below, in
2013-07-02 07:44:04 +04:00
order to maximize parallelization. If a daemon
2010-07-06 05:20:49 +04:00
implements a D-Bus service or listening socket,
implementing the full bus and socket activation scheme
allows starting of the daemon with its clients in
parallel (which speeds up boot-up), since all its
communication channels are established already, and no
request is lost because client requests will be queued
by the bus system (in case of D-Bus) or the kernel (in
2013-07-02 07:44:04 +04:00
case of sockets) until the activation is
2010-07-06 05:20:49 +04:00
completed.</para>
<refsect2 >
<title > Activation on Boot</title>
<para > Old-style daemons are usually activated
exclusively on boot (and manually by the
administrator) via SysV init scripts, as
detailed in the <ulink
url="http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB
Linux Standard Base Core
Specification</ulink> . This method of
2011-04-23 23:55:24 +04:00
activation is supported ubiquitously on Linux
2010-07-06 05:20:49 +04:00
init systems, both old-style and new-style
2013-07-02 07:44:04 +04:00
systems. Among other issues, SysV init scripts
2010-07-06 05:20:49 +04:00
have the disadvantage of involving shell
scripts in the boot process. New-style init
systems generally employ updated versions of
activation, both during boot-up and during
runtime and using more minimal service
description files.</para>
<para > In systemd, if the developer or
2013-12-26 05:47:45 +04:00
administrator wants to make sure that a service or
2013-07-02 07:44:04 +04:00
other unit is activated automatically on boot,
2010-07-06 05:20:49 +04:00
it is recommended to place a symlink to the
unit file in the <filename > .wants/</filename>
directory of either
<filename > multi-user.target</filename> or
<filename > graphical.target</filename> , which
are normally used as boot targets at system
startup. See
<citerefentry > <refentrytitle > systemd.unit</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
for details about the
<filename > .wants/</filename> directories, and
<citerefentry > <refentrytitle > systemd.special</refentrytitle> <manvolnum > 7</manvolnum> </citerefentry>
for details about the two boot targets.</para>
</refsect2>
2010-06-22 04:42:10 +04:00
<refsect2 >
2010-07-03 21:54:00 +04:00
<title > Socket-Based Activation</title>
2010-07-06 05:20:49 +04:00
<para > In order to maximize the possible
parallelization and robustness and simplify
configuration and development, it is
recommended for all new-style daemons that
communicate via listening sockets to employ
socket-based activation. In a socket-based
2013-07-02 07:44:04 +04:00
activation scheme, the creation and binding of
2010-07-06 05:20:49 +04:00
the listening socket as primary communication
channel of daemons to local (and sometimes
remote) clients is moved out of the daemon
code and into the init system. Based on
2013-07-02 07:44:04 +04:00
per-daemon configuration, the init system
2010-07-06 05:20:49 +04:00
installs the sockets and then hands them off
to the spawned process as soon as the
respective daemon is to be started.
2013-07-02 07:44:04 +04:00
Optionally, activation of the service can be
2010-07-06 05:20:49 +04:00
delayed until the first inbound traffic
2013-07-02 07:44:04 +04:00
arrives at the socket to implement on-demand
2010-07-06 05:20:49 +04:00
activation of daemons. However, the primary
advantage of this scheme is that all providers
and all consumers of the sockets can be
2010-08-25 05:10:13 +04:00
started in parallel as soon as all sockets
2013-07-02 07:44:04 +04:00
are established. In addition to that, daemons
2010-07-06 05:20:49 +04:00
can be restarted with losing only a minimal
2013-07-02 07:44:04 +04:00
number of client transactions, or even any
2010-07-06 05:20:49 +04:00
client request at all (the latter is
particularly true for state-less protocols,
such as DNS or syslog), because the socket
stays bound and accessible during the restart,
and all requests are queued while the daemon
cannot process them.</para>
<para > New-style daemons which support socket
activation must be able to receive their
2013-07-02 07:44:04 +04:00
sockets from the init system instead of
2010-07-06 05:20:49 +04:00
creating and binding them themselves. For
details about the programming interfaces for
2013-07-02 07:44:04 +04:00
this scheme provided by systemd, see
2010-07-06 05:20:49 +04:00
<citerefentry > <refentrytitle > sd_listen_fds</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry>
and
2012-07-13 03:50:05 +04:00
<citerefentry > <refentrytitle > sd-daemon</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry> . For
2010-07-06 05:20:49 +04:00
details about porting existing daemons to
2013-07-02 07:44:04 +04:00
socket-based activation, see below. With
minimal effort, it is possible to implement
2010-07-06 05:20:49 +04:00
socket-based activation in addition to
traditional internal socket creation in the
same codebase in order to support both
new-style and old-style init systems from the
same daemon binary.</para>
<para > systemd implements socket-based
activation via <filename > .socket</filename>
units, which are described in
<citerefentry > <refentrytitle > systemd.socket</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> . When
configuring socket units for socket-based
2013-07-02 07:44:04 +04:00
activation, it is essential that all listening
2010-07-06 05:20:49 +04:00
sockets are pulled in by the special target
unit <filename > sockets.target</filename> . It
is recommended to place a
<varname > WantedBy=sockets.target</varname>
directive in the <literal > [Install]</literal>
2013-07-02 07:44:04 +04:00
section to automatically add such a
2010-07-06 05:20:49 +04:00
dependency on installation of a socket
unit. Unless
<varname > DefaultDependencies=no</varname> is
2013-07-02 07:44:04 +04:00
set, the necessary ordering dependencies are
2010-07-06 05:20:49 +04:00
implicitly created for all socket units. For
more information about
2013-07-02 07:44:04 +04:00
<filename > sockets.target</filename> , see
2010-07-06 05:20:49 +04:00
<citerefentry > <refentrytitle > systemd.special</refentrytitle> <manvolnum > 7</manvolnum> </citerefentry> . It
is not necessary or recommended to place any
additional dependencies on socket units (for
example from
<filename > multi-user.target</filename> or
suchlike) when one is installed in
<filename > sockets.target</filename> .</para>
2010-06-22 04:42:10 +04:00
</refsect2>
<refsect2 >
2010-07-03 21:54:00 +04:00
<title > Bus-Based Activation</title>
2010-07-06 05:20:49 +04:00
<para > When the D-Bus IPC system is used for
communication with clients, new-style daemons
should employ bus activation so that they are
automatically activated when a client
application accesses their IPC
interfaces. This is configured in D-Bus
service files (not to be confused with systemd
service unit files!). To ensure that D-Bus
uses systemd to start-up and maintain the
2013-07-02 07:44:04 +04:00
daemon, use the
2010-07-06 05:20:49 +04:00
<varname > SystemdService=</varname> directive
2013-07-02 07:44:04 +04:00
in these service files to configure the
2010-07-06 05:20:49 +04:00
matching systemd service for a D-Bus
2013-07-02 07:44:04 +04:00
service. e.g.: For a D-Bus service whose D-Bus
2010-07-06 05:20:49 +04:00
activation file is named
<filename > org.freedesktop.RealtimeKit.service</filename> ,
make sure to set
<varname > SystemdService=rtkit-daemon.service</varname>
2013-07-02 07:44:04 +04:00
in that file to bind it to the systemd
2010-07-06 05:20:49 +04:00
service
<filename > rtkit-daemon.service</filename> . This
is needed to make sure that the daemon is
started in a race-free fashion when activated
via multiple mechanisms simultaneously.</para>
</refsect2>
<refsect2 >
<title > Device-Based Activation</title>
<para > Often, daemons that manage a particular
type of hardware should be activated only when
the hardware of the respective kind is plugged
in or otherwise becomes available. In a
2013-07-02 07:44:04 +04:00
new-style init system, it is possible to bind
2010-07-24 02:53:33 +04:00
activation to hardware plug/unplug events. In
systemd, kernel devices appearing in the
sysfs/udev device tree can be exposed as units
if they are tagged with the string
2013-06-26 16:03:53 +04:00
<literal > systemd</literal> . Like any other
2013-07-02 07:44:04 +04:00
kind of unit, they may then pull in other units
when activated (i.e. plugged in) and thus
implement device-based activation. systemd
2010-07-06 05:20:49 +04:00
dependencies may be encoded in the udev
database via the
<varname > SYSTEMD_WANTS=</varname>
property. See
<citerefentry > <refentrytitle > systemd.device</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
2013-07-02 07:44:04 +04:00
for details. Often, it is nicer to pull in
2010-07-06 05:20:49 +04:00
services from devices only indirectly via
2013-07-02 07:44:04 +04:00
dedicated targets. Example: Instead of pulling
2010-07-06 05:20:49 +04:00
in <filename > bluetoothd.service</filename>
from all the various bluetooth dongles and
other hardware available, pull in
bluetooth.target from them and
<filename > bluetoothd.service</filename> from
that target. This provides for nicer
abstraction and gives administrators the
option to enable
<filename > bluetoothd.service</filename> via
controlling a
<filename > bluetooth.target.wants/</filename>
2010-07-24 02:53:33 +04:00
symlink uniformly with a command like
<command > enable</command> of
<citerefentry > <refentrytitle > systemctl</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry>
2010-07-06 05:20:49 +04:00
instead of manipulating the udev
ruleset.</para>
2010-06-22 04:42:10 +04:00
</refsect2>
<refsect2 >
2010-07-03 21:54:00 +04:00
<title > Path-Based Activation</title>
2010-07-06 05:20:49 +04:00
<para > Often, runtime of daemons processing
spool files or directories (such as a printing
system) can be delayed until these file system
objects change state, or become
non-empty. New-style init systems provide a
way to bind service activation to file system
changes. systemd implements this scheme via
path-based activation configured in
<filename > .path</filename> units, as outlined
in
<citerefentry > <refentrytitle > systemd.path</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> .</para>
</refsect2>
<refsect2 >
<title > Timer-Based Activation</title>
<para > Some daemons that implement clean-up
jobs that are intended to be executed in
regular intervals benefit from timer-based
activation. In systemd, this is implemented
via <filename > .timer</filename> units, as
described in
<citerefentry > <refentrytitle > systemd.timer</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> .</para>
2010-07-03 21:54:00 +04:00
</refsect2>
2010-07-06 05:20:49 +04:00
<refsect2 >
<title > Other Forms of Activation</title>
<para > Other forms of activation have been
suggested and implemented in some
2013-07-02 07:44:04 +04:00
systems. However, there are often simpler or
2010-07-06 05:20:49 +04:00
better alternatives, or they can be put
together of combinations of the schemes
2013-07-02 07:44:04 +04:00
above. Example: Sometimes, it appears useful to
2010-07-06 05:20:49 +04:00
start daemons or <filename > .socket</filename>
units when a specific IP address is configured
on a network interface, because network
sockets shall be bound to the
address. However, an alternative to implement
this is by utilizing the Linux IP_FREEBIND
socket option, as accessible via
<varname > FreeBind=yes</varname> in systemd
socket files (see
<citerefentry > <refentrytitle > systemd.socket</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
for details). This option, when enabled,
allows sockets to be bound to a non-local, not
configured IP address, and hence allows
bindings to a particular IP address before it
actually becomes available, making such an
explicit dependency to the configured address
redundant. Another often suggested trigger for
service activation is low system
load. However, here too, a more convincing
approach might be to make proper use of
2013-07-02 07:44:04 +04:00
features of the operating system, in
2010-07-06 05:20:49 +04:00
particular, the CPU or IO scheduler of
Linux. Instead of scheduling jobs from
userspace based on monitoring the OS
scheduler, it is advisable to leave the
scheduling of processes to the OS scheduler
itself. systemd provides fine-grained access
to the CPU and IO schedulers. If a process
executed by the init system shall not
negatively impact the amount of CPU or IO
2010-12-16 03:55:59 +03:00
bandwidth available to other processes, it
2010-07-06 05:20:49 +04:00
should be configured with
<varname > CPUSchedulingPolicy=idle</varname>
and/or
<varname > IOSchedulingClass=idle</varname> . Optionally,
this may be combined with timer-based
activation to schedule background jobs during
runtime and with minimal impact on the system,
and remove it from the boot phase
itself.</para>
</refsect2>
</refsect1>
<refsect1 >
<title > Integration with Systemd</title>
2010-07-03 21:54:00 +04:00
<refsect2 >
<title > Writing Systemd Unit Files</title>
<para > When writing systemd unit files, it is
recommended to consider the following
suggestions:</para>
<orderedlist >
2013-07-02 07:44:04 +04:00
<listitem > <para > If possible, do not use
2010-07-03 21:54:00 +04:00
the <varname > Type=forking</varname>
setting in service files. But if you
do, make sure to set the PID file path
using <varname > PIDFile=</varname> . See
<citerefentry > <refentrytitle > systemd.service</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
for details.</para> </listitem>
<listitem > <para > If your daemon
registers a D-Bus name on the bus,
make sure to use
2010-07-10 02:49:00 +04:00
<varname > Type=dbus</varname> in the
service file if
2010-07-03 21:54:00 +04:00
possible.</para> </listitem>
<listitem > <para > Make sure to set a
good human-readable description string
with
<varname > Description=</varname> .</para> </listitem>
<listitem > <para > Do not disable
<varname > DefaultDependencies=</varname> ,
unless you really know what you do and
your unit is involved in early boot or
late system shutdown.</para> </listitem>
<listitem > <para > Normally, little if
any dependencies should need to
be defined explicitly. However, if you
do configure explicit dependencies, only refer to
unit names listed on
<citerefentry > <refentrytitle > systemd.special</refentrytitle> <manvolnum > 7</manvolnum> </citerefentry>
or names introduced by your own
package to keep the unit file
operating
system-independent.</para> </listitem>
<listitem > <para > Make sure to include
2010-07-10 02:49:00 +04:00
an <literal > [Install]</literal>
section including installation
information for the unit file. See
2010-07-03 21:54:00 +04:00
<citerefentry > <refentrytitle > systemd.unit</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
for details. To activate your service
2013-07-02 07:44:04 +04:00
on boot, make sure to add a
2010-07-03 21:54:00 +04:00
<varname > WantedBy=multi-user.target</varname>
or
2010-07-10 02:49:00 +04:00
<varname > WantedBy=graphical.target</varname>
directive. To activate your socket on
boot, make sure to add
2013-07-02 07:44:04 +04:00
<varname > WantedBy=sockets.target</varname> . Usually,
2010-07-10 02:49:00 +04:00
you also want to make sure that when
2013-07-02 07:44:04 +04:00
your service is installed, your socket
2010-07-10 02:49:00 +04:00
is installed too, hence add
<varname > Also=foo.socket</varname> in
your service file
<filename > foo.service</filename> , for
a hypothetical program
<filename > foo</filename> .</para> </listitem>
2010-07-03 21:54:00 +04:00
</orderedlist>
2010-06-22 04:42:10 +04:00
</refsect2>
<refsect2 >
2010-07-06 05:20:49 +04:00
<title > Installing Systemd Service Files</title>
2010-07-03 21:54:00 +04:00
<para > At the build installation time
(e.g. <command > make install</command> during
2013-07-02 07:44:04 +04:00
package build), packages are recommended to
2010-07-03 21:54:00 +04:00
install their systemd unit files in the
directory returned by <command > pkg-config
systemd
2010-07-24 02:53:33 +04:00
--variable=systemdsystemunitdir</command> (for
Reword sentences that contain psuedo-English "resp."
As you likely know, Arch Linux is in the process of moving to systemd.
So I was reading through the various systemd docs and quickly became
baffled by this new abbreviation "resp.", which I've never seen before
in my English-mother-tongue life.
Some quick Googling turned up a reference:
<http://www.transblawg.eu/index.php?/archives/870-Resp.-and-other-non-existent-English-wordsNicht-existente-englische-Woerter.html>
I guess it's a literal translation of the German "Beziehungsweise", but
English doesn't work the same way. The word "respectively" is used
exclusively to provide an ordering connection between two lists. E.g.
"the prefixes k, M, and G refer to kilo-, mega-, and giga-,
respectively." It is also never abbreviated to "resp." So the sentence
"Sets the default output resp. error output for all services and
sockets" makes no sense to a natural English speaker.
This patch removes all instances of "resp." in the man pages and
replaces them with sentences which are much more clear and, hopefully,
grammatically valid. In almost all instances, it was simply replacing
"resp." with "or," which the original author (Lennart?) could probably
just do in the future.
The only other instances of "resp." are in the src/ subtree, which I
don't feel privileged to correct.
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
2012-10-15 22:59:12 +04:00
system services) or <command > pkg-config
2010-07-24 02:53:33 +04:00
systemd
2010-11-16 00:12:41 +03:00
--variable=systemduserunitdir</command>
(for user services). This will make the
2010-07-03 21:54:00 +04:00
services available in the system on explicit
request but not activate them automatically
during boot. Optionally, during package
installation (e.g. <command > rpm -i</command>
2013-07-02 07:44:04 +04:00
by the administrator), symlinks should be
2010-07-03 21:54:00 +04:00
created in the systemd configuration
2010-07-24 02:53:33 +04:00
directories via the <command > enable</command>
command of the
<citerefentry > <refentrytitle > systemctl</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry>
2013-07-02 07:44:04 +04:00
tool to activate them automatically on
2010-07-03 21:54:00 +04:00
boot.</para>
<para > Packages using
<citerefentry > <refentrytitle > autoconf</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry>
are recommended to use a configure script
excerpt like the following to determine the
unit installation path during source
configuration:</para>
<programlisting > PKG_PROG_PKG_CONFIG
AC_ARG_WITH([systemdsystemunitdir],
2014-02-16 16:42:17 +04:00
[AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files])],,
2013-12-28 08:44:27 +04:00
[with_systemdsystemunitdir=auto])
AS_IF([test "x$with_systemdsystemunitdir" = "xyes" -o "x$with_systemdsystemunitdir" = "xauto"], [
def_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)
AS_IF([test "x$def_systemdsystemunitdir" = "x"],
[AS_IF([test "x$with_systemdsystemunitdir" = "xyes"],
[AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])])
with_systemdsystemunitdir=no],
2014-02-16 16:42:17 +04:00
[with_systemdsystemunitdir="$def_systemdsystemunitdir"])])
2013-12-28 08:44:27 +04:00
AS_IF([test "x$with_systemdsystemunitdir" != "xno"],
[AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])])
2014-02-16 16:42:17 +04:00
AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])</programlisting>
2010-07-03 21:54:00 +04:00
<para > This snippet allows automatic
installation of the unit files on systemd
machines, and optionally allows their
installation even on machines lacking
systemd. (Modification of this snippet for the
2011-06-18 17:40:20 +04:00
user unit directory is left as an exercise for the
2010-07-03 21:54:00 +04:00
reader.)</para>
<para > Additionally, to ensure that
<command > make distcheck</command> continues to
work, it is recommended to add the following
to the top-level <filename > Makefile.am</filename>
file in
<citerefentry > <refentrytitle > automake</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> -based
projects:</para>
<programlisting > DISTCHECK_CONFIGURE_FLAGS = \
--with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)</programlisting>
<para > Finally, unit files should be installed in the system with an automake excerpt like the following:</para>
<programlisting > if HAVE_SYSTEMD
systemdsystemunit_DATA = \
foobar.socket \
foobar.service
endif</programlisting>
<para > In the
<citerefentry > <refentrytitle > rpm</refentrytitle> <manvolnum > 8</manvolnum> </citerefentry>
2013-07-02 07:44:04 +04:00
<filename > .spec</filename> file, use snippets
2012-06-22 00:36:37 +04:00
like the following to enable/disable the
service during
installation/deinstallation. This makes use of
the RPM macros shipped along systemd. Consult
2010-07-03 21:54:00 +04:00
the packaging guidelines of your distribution
for details and the equivalent for other
2012-06-22 00:36:37 +04:00
package managers.</para>
<para > At the top of the file:</para>
<programlisting > BuildRequires: systemd
%{?systemd_requires}</programlisting>
<para > And as scriptlets, further down:</para>
2010-07-03 21:54:00 +04:00
<programlisting > %post
2012-06-22 00:36:37 +04:00
%systemd_post foobar.service foobar.socket
2010-07-03 21:54:00 +04:00
%preun
2012-06-22 00:36:37 +04:00
%systemd_preun foobar.service foobar.socket
2010-07-24 02:53:33 +04:00
%postun
2012-06-22 00:36:37 +04:00
%systemd_postun</programlisting>
<para > If the service shall be restarted during
2013-07-02 07:44:04 +04:00
upgrades, replace the
2012-06-22 00:36:37 +04:00
<literal > %postun</literal> scriptlet above
with the following:</para>
<programlisting > %postun
%systemd_postun_with_restart foobar.service</programlisting>
<para > Note that
<literal > %systemd_post</literal> and
<literal > %systemd_preun</literal> expect the
names of all units that are installed/removed
as arguments, separated by
spaces. <literal > %systemd_postun</literal>
expects no
arguments. <literal > %systemd_postun_with_restart</literal>
expects the units to restart as
arguments.</para>
2010-07-10 02:49:00 +04:00
2010-08-06 13:59:37 +04:00
<para > To facilitate upgrades from a package
version that shipped only SysV init scripts to
a package version that ships both a SysV init
script and a native systemd service file, use
a fragment like the following:</para>
2010-09-13 22:51:40 +04:00
<programlisting > %triggerun -- foobar < 0.47.11-1
2011-04-16 04:42:23 +04:00
if /sbin/chkconfig --level 5 foobar ; then
2011-02-18 04:25:18 +03:00
/bin/systemctl --no-reload enable foobar.service foobar.socket >/dev/null 2>& 1 || :
2010-08-06 13:59:37 +04:00
fi</programlisting>
<para > Where 0.47.11-1 is the first package
version that includes the native unit
file. This fragment will ensure that the first
2013-07-02 07:44:04 +04:00
time the unit file is installed, it will be
2010-08-06 13:59:37 +04:00
enabled if and only if the SysV init script is
2010-08-07 20:09:39 +04:00
enabled, thus making sure that the enable
2010-08-06 13:59:37 +04:00
status is not changed. Note that
<command > chkconfig</command> is a command
2010-08-06 23:36:58 +04:00
specific to Fedora which can be used to check
2010-08-06 13:59:37 +04:00
whether a SysV init script is enabled. Other
operating systems will have to use different
commands here.</para>
2010-07-03 21:54:00 +04:00
</refsect2>
2010-06-22 04:42:10 +04:00
</refsect1>
2010-07-06 05:20:49 +04:00
<refsect1 >
<title > Porting Existing Daemons</title>
<para > Since new-style init systems such as systemd are
2013-07-02 07:44:04 +04:00
compatible with traditional SysV init systems, it is
2010-07-06 05:20:49 +04:00
not strictly necessary to port existing daemons to the
2013-07-02 07:44:04 +04:00
new style. However, doing so offers additional
2010-07-07 05:24:38 +04:00
functionality to the daemons as well as simplifying
2010-07-06 05:20:49 +04:00
integration into new-style init systems.</para>
2013-07-02 07:44:04 +04:00
<para > To port an existing SysV compatible daemon, the
2010-07-06 05:20:49 +04:00
following steps are recommended:</para>
<orderedlist >
<listitem > <para > If not already implemented,
add an optional command line switch to the
daemon to disable daemonization. This is
useful not only for using the daemon in
new-style init systems, but also to ease
debugging.</para> </listitem>
<listitem > <para > If the daemon offers
interfaces to other software running on the
2013-06-27 03:47:34 +04:00
local system via local <constant > AF_UNIX</constant> sockets,
2010-07-06 05:20:49 +04:00
consider implementing socket-based activation
2013-07-02 07:44:04 +04:00
(see above). Usually, a minimal patch is
2010-07-06 05:20:49 +04:00
sufficient to implement this: Extend the
socket creation in the daemon code so that
<citerefentry > <refentrytitle > sd_listen_fds</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry>
is checked for already passed sockets
first. If sockets are passed (i.e. when
<function > sd_listen_fds()</function> returns a
positive value), skip the socket creation step
and use the passed sockets. Secondly, ensure
2013-05-18 13:28:25 +04:00
that the file system socket nodes for local
2013-06-27 03:47:34 +04:00
<constant > AF_UNIX</constant> sockets used in the socket-based
2010-07-06 05:20:49 +04:00
activation are not removed when the daemon
shuts down, if sockets have been
passed. Third, if the daemon normally closes
all remaining open file descriptors as part of
its initialization, the sockets passed from
the init system must be spared. Since
new-style init systems guarantee that no
left-over file descriptors are passed to
executed processes, it might be a good choice
to simply skip the closing of all remaining
2010-07-07 05:24:38 +04:00
open file descriptors if sockets are
2010-07-06 05:20:49 +04:00
passed.</para> </listitem>
<listitem > <para > Write and install a systemd
unit file for the service (and the sockets if
socket-based activation is used, as well as a
path unit file, if the daemon processes a
spool directory), see above for
details.</para> </listitem>
<listitem > <para > If the daemon exposes
interfaces via D-Bus, write and install a
D-Bus activation file for the service, see
above for details.</para> </listitem>
</orderedlist>
</refsect1>
2010-06-22 04:42:10 +04:00
<refsect1 >
2010-06-24 02:11:04 +04:00
<title > See Also</title>
<para >
<citerefentry > <refentrytitle > systemd</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> ,
2012-07-13 03:50:05 +04:00
<citerefentry > <refentrytitle > sd-daemon</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry> ,
2010-07-03 21:54:00 +04:00
<citerefentry > <refentrytitle > sd_listen_fds</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > sd_notify</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry> ,
2010-07-06 05:20:49 +04:00
<citerefentry > <refentrytitle > daemon</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > systemd.service</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
2010-06-24 02:11:04 +04:00
</para>
2010-06-22 04:42:10 +04:00
</refsect1>
</refentry>