<filename>default.target</filename>.</para></listitem>
</varlistentry>
<varlistentry>
- <term><option>--running-as=</option></term>
-
- <listitem><para>Tell systemd to run in
- a particular mode. Argument is one of
- <option>system</option>,
- <option>session</option>. Normally it
- should not be necessary to pass this
- option, as systemd automatically
- detects the mode it is started
- in. This call is hence of little use
- except for
+ <term><option>--system</option></term>
+ <term><option>--session</option></term>
+
+ <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. systemd is not
+ (resp. is) run as init process.
+ Normally it should not be necessary to
+ pass these options, as systemd
+ automatically detects the mode it is
+ started in. These options are hence of
+ little use except for
debugging.</para></listitem>
</varlistentry>
<varlistentry>
<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
+ and maintenance. 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 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
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>
+ <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
<listitem><para>Timer units are useful for
triggering activation of other units based on
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
when figuring out whether a service
shall be enabled. Note that a service
unit with a native unit configuration
- file can be started by activating it
+ file cannot be started by activating it
in the SysV runlevel link
farm.</para></listitem>
</varlistentry>
~ianmdlvl / elogind.git / blobdiff