+
+ <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>
+ </refsect2>
+
+ </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
+ unconditionally it is a good idea to implement some of
+ the various activation schemes outlined below, in
+ order to maximize parallelization: if a daemon
+ 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
+ case of sockets), until the activation
+ 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
+ activation is supported ubiquitiously on Linux
+ init systems, both old-style and new-style
+ systems. Among other issues SysV init scripts
+ 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
+ administrator wants to make sure a service or
+ other unit is activated automatically on boot
+ 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>
+
+ <refsect2>
+ <title>Socket-Based Activation</title>
+
+ <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
+ activation scheme the creation and binding of
+ 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
+ per-daemon configuration the init system
+ installs the sockets and then hands them off
+ to the spawned process as soon as the
+ respective daemon is to be started.
+ Optionally activation of the service can be
+ delayed until the first inbound traffic
+ arrives at the socket, to implement on-demand
+ activation of daemons. However, the primary
+ advantage of this scheme is that all providers
+ and all consumers of the sockets can be
+ started in parallel as soon als all sockets
+ are established. In addition to that daemons
+ can be restarted with losing only a minimal
+ number of client transactions or even any
+ 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
+ sockets from the init system, instead of of
+ creating and binding them themselves. For
+ details about the programming interfaces for
+ this scheme provided by systemd see
+ <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+ and
+ <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>. For
+ details about porting existing daemons to
+ socket-based activation see below. With
+ minimal effort it is possible to implement
+ 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
+ activation it is essential that all listening
+ 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>
+ section, to automatically add such a
+ dependency on installation of a socket
+ unit. Unless
+ <varname>DefaultDependencies=no</varname> is
+ set the necessary ordering dependencies are
+ implicitly created for all socket units. For
+ more information about
+ <filename>sockets.target</filename> see
+ <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>
+ </refsect2>
+
+ <refsect2>
+ <title>Bus-Based Activation</title>
+
+ <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
+ daemon use the
+ <varname>SystemdService=</varname> directive
+ in these service files, to configure the
+ matching systemd service for a D-Bus
+ service. e.g.: for a D-Bus service whose D-Bus
+ activation file is named
+ <filename>org.freedesktop.RealtimeKit.service</filename>,
+ make sure to set
+ <varname>SystemdService=rtkit-daemon.service</varname>
+ in that file, to bind it to the systemd
+ 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>