1
1
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-23 17:34:00 +03:00

man: add missing parts to man pages

This commit is contained in:
Lennart Poettering 2010-07-06 03:20:49 +02:00
parent c59760eeda
commit 99ffae46d3
3 changed files with 503 additions and 101 deletions

View File

@ -57,7 +57,10 @@
in SysV Unix. Modern daemons should follow a simpler
yet more powerful scheme (here called "new-style"
daemons), as implemented by
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>. </para>
<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>
<refsect2>
<title>SysV Daemons</title>
@ -252,26 +255,35 @@
recommendations for SysV init
scripts</ulink>.</para></listitem>
<listitem><para>As much as possible,
rely on systemd's functionality to
limit the access of the daemon to
files, services and other
resources. i.e. 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>
<listitem><para>If possible and
applicable expose the daemon's control
interface via the D-Bus IPC system and
grab a bus name as last step of
initialization.</para></listitem>
<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,
rely on the init systemd's
functionality to limit the access of
the daemon to files, services and
other resources. i.e. in the case of
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>
<listitem><para>If D-Bus is used, make
your daemon bus-activatable, via
supplying a D-Bus service activation
@ -345,18 +357,308 @@
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>
</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
new-style init system it is possible to bind
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
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>
for details. Often it is nicer to pull in
services from devices only indirectly via
dedicated targets. Example: instead of pulling
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>
symlink uniformly with a tool like
<citerefentry><refentrytitle>systemd-install</refentrytitle><manvolnum>1</manvolnum></citerefentry>
instead of manipulating the udev
ruleset.</para>
</refsect2>
<refsect2>
<title>Path-Based Activation</title>
<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>
</refsect2>
<refsect2>
<title>Other Forms of Activation</title>
<para>Other forms of activation have been
suggested and implemented in some
systems. However, often there are simpler or
better alternatives, or they can be put
together of combinations of the schemes
above. Example: sometimes it appears useful to
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
features of the operating system: in
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
bandwith available to other processes, it
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>
<refsect2>
<title>Writing Systemd Unit Files</title>
@ -416,7 +718,7 @@
</refsect2>
<refsect2>
<title>Installing Service Files</title>
<title>Installing Systemd Service Files</title>
<para>At the build installation time
(e.g. <command>make install</command> during
@ -488,7 +790,7 @@ endif</programlisting>
during installation/deinstallation. Consult
the packaging guidelines of your distribution
for details and the equivalent for other
packaging managers:</para>
package managers:</para>
<programlisting>%post
/usr/bin/systemd-install enable foobar.service foobar.socket >/dev/null 2>&amp;1 || :
@ -499,85 +801,70 @@ if [ "$1" -eq 0 ]; then
fi</programlisting>
</refsect2>
<refsect2>
<title>Porting Existing Daemons</title>
<para>Since new-style init systems such as
systemd are compatible with traditional SysV
init systems it is not strictly necessary to
port existing daemons to the new
style. However doing this offers additional
functionality to the daemons as well as it
simplifies integration into new-style init
systems.</para>
<para>To port an existing SysV compatible
daemon the 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 local system via local AF_UNIX
sockets, consider implementing
socket-based activation (see
above). Usually a minimal patch is
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 createn step and use the passed
sockets. Secondly, ensure that the
file-system socket nodes for local
AF_UNIX sockets used in the
socket-based 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 open file descriptors if
file descriptors are
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>
</refsect2>
</refsect1>
<refsect1>
<title>Porting Existing Daemons</title>
<para>Since new-style init systems such as systemd are
compatible with traditional SysV init systems it is
not strictly necessary to port existing daemons to the
new style. However doing this offers additional
functionality to the daemons as well as it simplifies
integration into new-style init systems.</para>
<para>To port an existing SysV compatible daemon the
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
local system via local AF_UNIX sockets,
consider implementing socket-based activation
(see above). Usually a minimal patch is
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
that the file-system socket nodes for local
AF_UNIX sockets used in the socket-based
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
open file descriptors if file descriptors are
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>
<refsect1>
<title>See Also</title>
@ -587,7 +874,8 @@ fi</programlisting>
<citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>7</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>
<citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
</para>
</refsect1>

View File

@ -64,9 +64,11 @@
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for the common options of all unit configuration
files. The common configuration items are configured
in the generic [Unit] and [Install] sections. A
separate [Device] section does not exist, since no
device-specific options may be configured.</para>
in the generic <literal>[Unit]</literal> and
<literal>[Install]</literal> sections. A separate
<literal>[Device]</literal> section does not exist,
since no device-specific options may be
configured.</para>
<para>systemd will automatically create dynamic device
units for all kernel devices that are marked with the
@ -100,9 +102,15 @@
<listitem><para>Adds dependencies of
type <varname>Wants</varname> from
this unit to all listed units. This
may be used to activate arbitrary units,
when a specific device becomes
available.</para></listitem>
may be used to activate arbitrary
units, when a specific device becomes
available. Note that this and the
other tags are not taken into account
unless the device is tagged with the
"<literal>systemd</literal>" string in
the udev database, because otherwise
the device is not exposed as systemd
unit.</para></listitem>
</varlistentry>
<varlistentry>

View File

@ -196,6 +196,112 @@
</variablelist>
</refsect1>
<refsect1>
<title>Concepts</title>
<para>systemd provides a dependency system between
various entities called "units". Units encapsulate
various objects that are relevant for system boot-up
and maintainance. The majority of units are configured
in unit configuration files, whose syntax and basic
set of options is described in
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
however some are created automatically from other
configuration or dynamically from system state. Units
may be active (meaning started, bound, plugged in, ...
depending on the unit type), or inactive (meaning
stopped, unbound, unplugged, ...), as well is in the
process of being activated or deactivated,
i.e. between the two states. The following unit types
are available:</para>
<orderedlist>
<listitem><para>Service units, which control
daemons and the processes they consist of. For
details see
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
<listitem><para>Socket units, which
encapsulate local IPC or network sockets in
the system, useful for socket-based
activation. For details about socket units see
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
for details on socket-based activation and
other forms of activation, see
<citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
<listitem><para>Target units are useful to
group units, or provide well-known
synchronization points during boot-up, see
<citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
<listitem><para>Device units expose kernel
devices in systemd and may be used to
implement device-based activation. For details
see
<citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
<listitem><para>Mount units control mount
points in the file system, for details see
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
<listitem><para>Automount units provide
automount capabilities, for on-demand mounting
of file systems as well as parallelized
boot-up. See
<citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
<listitem><para>Snapshot units can be used to
temporarily save the state of the set of
systemd units, which later may be restored by
activating the saved snapshot unit. For more
information see
<citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
<listitem><para>Timer units are useful for
triggering activation of other units based on
timers. You may find details in
<citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
<listitem><para>Swap units are very similar to
mount units and encapsulated memory swap
partitions or files of the operating
systemd. They are described in <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
<listitem><para>Path units may be used
activate other services when file system
objects change or are modified. See
<citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
</orderedlist>
<para>Units are named as their configuration
files. Some units have special semantics. A detailed
list you may find in
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
<para>On boot systemd activates the target unit
<filename>default.target</filename> whose job it is to
activate on-boot services and other on-boot units by
pulling them in via dependencies. Usually the unit
name is just an alias (symlink) for either
<filename>graphical.target</filename> (for
fully-featured boots into the UI) or
<filename>multi-user.target</filename> (for limited
console-only boots for use in embedded or server
environments, or similar; a subset of
graphical.target). However it is at the discretion of
the administrator to configure it as an alias to any
other target unit. See
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
for details about these target units.</para>
<para>For more information about the concepts and
ideas behind systemd please refer to the <ulink
url="http://0pointer.de/blog/projects/systemd.html">Original
Announcement Document</ulink>.</para>
</refsect1>
<refsect1>
<title>Directories</title>