descriptors 0, 1, 2). This ensures
that no accidentally passed file
descriptor stays around in the daemon
descriptors 0, 1, 2). This ensures
that no accidentally passed file
descriptor stays around in the daemon
implemented by iterating through
<filename>/proc/self/fd</filename>,
with a fallback of iterating from file
implemented by iterating through
<filename>/proc/self/fd</filename>,
with a fallback of iterating from file
best done by iterating through the
available signals up to the limit of
_NSIG and resetting them to
best done by iterating through the
available signals up to the limit of
_NSIG and resetting them to
<listitem><para>In the child, call
<function>fork()</function> again, to
<listitem><para>In the child, call
<function>fork()</function> again, to
a terminal again.</para></listitem>
<listitem><para>Call <function>exit()</function> in the
first child, so that only the second
child (the actual daemon process)
stays around. This ensures that the
a terminal again.</para></listitem>
<listitem><para>Call <function>exit()</function> in the
first child, so that only the second
child (the actual daemon process)
stays around. This ensures that the
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
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
started that initialization is
complete. This can be implemented via
an unnamed pipe or similar
started that initialization is
complete. This can be implemented via
an unnamed pipe or similar
<function>exit()</function> in the
original process. The process that
invoked the daemon must be able to
<function>exit()</function> in the
original process. The process that
invoked the daemon must be able to
<function>exit()</function> happens
after initialization is complete and
all external communication channels
<function>exit()</function> happens
after initialization is complete and
all external communication channels
compatibility with SysV systems should
implement the scheme pointed out
above. However, it is recommended to make this
compatibility with SysV systems should
implement the scheme pointed out
above. However, it is recommended to make this
- behaviour optional and configurable via a
- command line argument, to ease debugging as
+ behavior optional and configurable via a
+ command line argument to ease debugging as
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
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
execute them when run as new-style
service.</para>
<para>Note that new-style init systems
guarantee execution of daemon processes in
execute them when run as new-style
service.</para>
<para>Note that new-style init systems
guarantee execution of daemon processes in
the environment block is sanitized, that the
signal handlers and mask is reset and that no
left-over file descriptors are passed. Daemons
the environment block is sanitized, that the
signal handlers and mask is reset and that no
left-over file descriptors are passed. Daemons
received, shut down the daemon and
exit cleanly.</para></listitem>
received, shut down the daemon and
exit cleanly.</para></listitem>
reload the configuration files, if
this applies.</para></listitem>
reload the configuration files, if
this applies.</para></listitem>
interface via the D-Bus IPC system and
grab a bus name as last step of
initialization.</para></listitem>
interface via the D-Bus IPC system and
grab a bus name as last step of
initialization.</para></listitem>
for details.</para></listitem>
<listitem><para>As much as possible,
for details.</para></listitem>
<listitem><para>As much as possible,
functionality to limit the access of
the daemon to files, services and
functionality to limit the access of
the daemon to files, services and
systemd, rely on systemd's resource
limit control instead of implementing
your own, rely on systemd's privilege
systemd, rely on systemd's resource
limit control instead of implementing
your own, rely on systemd's privilege
controls.</para></listitem>
<listitem><para>If D-Bus is used, make
controls.</para></listitem>
<listitem><para>If D-Bus is used, make
supplying a D-Bus service activation
configuration file. This has multiple
advantages: your daemon may be started
supplying a D-Bus service activation
configuration file. This has multiple
advantages: your daemon may be started
parallel to other daemons requiring it
-- which maximizes parallelization and
boot-up speed; your daemon can be
parallel to other daemons requiring it
-- which maximizes parallelization and
boot-up speed; your daemon can be
any bus requests, as the bus queues
requests for activatable services. See
below for details.</para></listitem>
any bus requests, as the bus queues
requests for activatable services. See
below for details.</para></listitem>
socket, it should be made
socket-activatable following the
scheme pointed out below. Like D-Bus
socket, it should be made
socket-activatable following the
scheme pointed out below. Like D-Bus
starting of services as well as it
allows improved parallelization of
service start-up. Also, for state-less
starting of services as well as it
allows improved parallelization of
service start-up. Also, for state-less
daemon implementing socket-based
activation can be restarted without
losing a single request. See below for
details.</para></listitem>
daemon implementing socket-based
activation can be restarted without
losing a single request. See below for
details.</para></listitem>
choose to simply log to STDERR via
<function>fprintf()</function>, which is then forwarded to
syslog by the init system. If log
choose to simply log to STDERR via
<function>fprintf()</function>, which is then forwarded to
syslog by the init system. If log
encoded by prefixing individual log
lines with strings like "<4>"
(for log priority 4 "WARNING" in the
encoded by prefixing individual log
lines with strings like "<4>"
(for log priority 4 "WARNING" in the
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
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
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
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
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
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
Specification</ulink>. This method of
activation is supported ubiquitously on Linux
init systems, both old-style and new-style
Specification</ulink>. This method of
activation is supported ubiquitously on Linux
init systems, both old-style and new-style
have the disadvantage of involving shell
scripts in the boot process. New-style init
systems generally employ updated versions of
have the disadvantage of involving shell
scripts in the boot process. New-style init
systems generally employ updated versions of
<para>In systemd, if the developer or
administrator wants to make sure a service or
<para>In systemd, if the developer or
administrator wants to make sure a service or
recommended for all new-style daemons that
communicate via listening sockets to employ
socket-based activation. In a socket-based
recommended for all new-style daemons that
communicate via listening sockets to employ
socket-based activation. In a socket-based
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
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
installs the sockets and then hands them off
to the spawned process as soon as the
respective daemon is to be started.
installs the sockets and then hands them off
to the spawned process as soon as the
respective daemon is to be started.
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 as all sockets
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 as all sockets
client request at all (the latter is
particularly true for state-less protocols,
such as DNS or syslog), because the socket
client request at all (the latter is
particularly true for state-less protocols,
such as DNS or syslog), because the socket
- socket-based activation see below. With
- minimal effort it is possible to implement
+ 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
socket-based activation in addition to
traditional internal socket creation in the
same codebase in order to support both
units, which are described in
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. When
configuring socket units for socket-based
units, which are described in
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. When
configuring socket units for socket-based
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>
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>
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>. It
is not necessary or recommended to place any
additional dependencies on socket units (for
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>. It
is not necessary or recommended to place any
additional dependencies on socket units (for
service files (not to be confused with systemd
service unit files!). To ensure that D-Bus
uses systemd to start-up and maintain the
service files (not to be confused with systemd
service unit files!). To ensure that D-Bus
uses systemd to start-up and maintain the
activation file is named
<filename>org.freedesktop.RealtimeKit.service</filename>,
make sure to set
<varname>SystemdService=rtkit-daemon.service</varname>
activation file is named
<filename>org.freedesktop.RealtimeKit.service</filename>,
make sure to set
<varname>SystemdService=rtkit-daemon.service</varname>
type of hardware should be activated only when
the hardware of the respective kind is plugged
in or otherwise becomes available. In a
type of hardware should be activated only when
the hardware of the respective kind is plugged
in or otherwise becomes available. In a
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
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
- "<literal>systemd</literal>". Like any other
- kind of unit they may then pull in other units
- when activated (i.e. Plugged in) and thus
- implement device-based activation. Systemd
+ <literal>systemd</literal>. Like any other
+ kind of unit, they may then pull in other units
+ when activated (i.e. plugged in) and thus
+ implement device-based activation. systemd
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>
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>
in <filename>bluetoothd.service</filename>
from all the various bluetooth dongles and
other hardware available, pull in
in <filename>bluetoothd.service</filename>
from all the various bluetooth dongles and
other hardware available, pull in
better alternatives, or they can be put
together of combinations of the schemes
better alternatives, or they can be put
together of combinations of the schemes
start daemons or <filename>.socket</filename>
units when a specific IP address is configured
on a network interface, because network
start daemons or <filename>.socket</filename>
units when a specific IP address is configured
on a network interface, because network
service activation is low system
load. However, here too, a more convincing
approach might be to make proper use of
service activation is low system
load. However, here too, a more convincing
approach might be to make proper use of
particular, the CPU or IO scheduler of
Linux. Instead of scheduling jobs from
userspace based on monitoring the OS
particular, the CPU or IO scheduler of
Linux. Instead of scheduling jobs from
userspace based on monitoring the OS
the <varname>Type=forking</varname>
setting in service files. But if you
do, make sure to set the PID file path
the <varname>Type=forking</varname>
setting in service files. But if you
do, make sure to set the PID file path
information for the unit file. See
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details. To activate your service
information for the unit file. See
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details. To activate your service
<varname>WantedBy=multi-user.target</varname>
or
<varname>WantedBy=graphical.target</varname>
directive. To activate your socket on
boot, make sure to add
<varname>WantedBy=multi-user.target</varname>
or
<varname>WantedBy=graphical.target</varname>
directive. To activate your socket on
boot, make sure to add
is installed too, hence add
<varname>Also=foo.socket</varname> in
your service file
is installed too, hence add
<varname>Also=foo.socket</varname> in
your service file
install their systemd unit files in the
directory returned by <command>pkg-config
systemd
--variable=systemdsystemunitdir</command> (for
install their systemd unit files in the
directory returned by <command>pkg-config
systemd
--variable=systemdsystemunitdir</command> (for
request but not activate them automatically
during boot. Optionally, during package
installation (e.g. <command>rpm -i</command>
request but not activate them automatically
during boot. Optionally, during package
installation (e.g. <command>rpm -i</command>
created in the systemd configuration
directories via the <command>enable</command>
command of the
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
created in the systemd configuration
directories via the <command>enable</command>
command of the
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
<para>Where 0.47.11-1 is the first package
version that includes the native unit
file. This fragment will ensure that the first
<para>Where 0.47.11-1 is the first package
version that includes the native unit
file. This fragment will ensure that the first
enabled if and only if the SysV init script is
enabled, thus making sure that the enable
status is not changed. Note that
enabled if and only if the SysV init script is
enabled, thus making sure that the enable
status is not changed. Note that
sufficient to implement this: Extend the
socket creation in the daemon code so that
<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
sufficient to implement this: Extend the
socket creation in the daemon code so that
<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
<function>sd_listen_fds()</function> returns a
positive value), skip the socket creation step
and use the passed sockets. Secondly, ensure
<function>sd_listen_fds()</function> returns a
positive value), skip the socket creation step
and use the passed sockets. Secondly, ensure
activation are not removed when the daemon
shuts down, if sockets have been
passed. Third, if the daemon normally closes
activation are not removed when the daemon
shuts down, if sockets have been
passed. Third, if the daemon normally closes
<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,