summaryrefslogtreecommitdiff
path: root/man/systemd.xml
diff options
context:
space:
mode:
authorLennart Poettering <lennart@poettering.net>2010-07-18 02:11:38 +0200
committerLennart Poettering <lennart@poettering.net>2010-07-18 02:11:38 +0200
commitb9975629f03a43d4c6b14fdb42eb8dd5a30af28f (patch)
tree75cc7fe189574ee751d3ddb7aaa38b9d143c7241 /man/systemd.xml
parent246756ca928adaee98edd0e67712e81d8f3255a6 (diff)
man: extend man pages a little
Diffstat (limited to 'man/systemd.xml')
-rw-r--r--man/systemd.xml54
1 files changed, 47 insertions, 7 deletions
diff --git a/man/systemd.xml b/man/systemd.xml
index e74d71b126..25f24ce722 100644
--- a/man/systemd.xml
+++ b/man/systemd.xml
@@ -141,7 +141,7 @@
<listitem><para>Tell systemd to run a
system instance (resp. session
instance), even if the process ID is
- not 1 (resp. is 1), i.e. system is not
+ not 1 (resp. is 1), i.e. systemd is not
(resp. is) run as init process.
Normally it should not be necessary to
pass these options, as systemd
@@ -232,12 +232,23 @@
<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 as in the
- process of being activated or deactivated,
- i.e. between the two states. The following unit types
- are available:</para>
+ may be 'active' (meaning started, bound, plugged in,
+ ... depending on the unit type, see below), or
+ 'inactive' (meaning stopped, unbound, unplugged, ...),
+ as well as in the process of being activated or
+ deactivated, i.e. between the two states (these states
+ are called 'activating', 'deactivating'). A special
+ 'maintenance' state is available as well which is very
+ similar to 'inactive' and is entered when the service
+ failed in some way (process returned error code on
+ exit, or crashed, or an operation timed out). If this
+ state is entered the cause will be logged, for later
+ reference. Note that the various unit types may have a
+ number of additional substates, which are mapped to
+ the five generalized unit states described
+ here.</para>
+
+ <para>The following unit types are available:</para>
<orderedlist>
<listitem><para>Service units, which control
@@ -304,6 +315,35 @@
list you may find in
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+ <para>systemd knows various kinds of dependencies,
+ including positive and negative requirement
+ dependencies (i.e. <varname>Requires=</varname> and
+ <varname>Conflicts=</varname>) as well as ordering
+ dependencies (<varname>After=</varname> and
+ <varname>Before=</varname>). NB: ordering and
+ requirement dependencies are orthogonal. If only a
+ requirement dependency exists between two units
+ (e.g. <filename>foo.service</filename> requires
+ <filename>bar.service</filename>), but no ordering
+ dependency (e.g. <filename>foo.service</filename>
+ after <filename>bar.service</filename>) and both are
+ requested to start, they will be started in
+ parallel. It is a common pattern that both requirement
+ and ordering dependencies are placed between two
+ units. Also note that the majority of dependencies are
+ implicitly created and maintained by systemd. In most
+ cases it should be unnecessary to declare additional
+ dependencies manually, however it is possible to do
+ this.</para>
+
+ <para>Application programs and units (via
+ dependencies) may requests state changes of units. In
+ systemd, these requests are encapsulated as 'jobs' and
+ maintained in a job queue. Jobs may succeed or can
+ fail, their execution is ordered based on the ordering
+ dependencies of the units they have been scheduled
+ for.</para>
+
<para>On boot systemd activates the target unit
<filename>default.target</filename> whose job is to
activate on-boot services and other on-boot units by