<listitem><para>Extract D-Bus
interface introspection data. This is
- mostly useful at build at install time
+ mostly useful at install time
to generate data suitable for the
D-Bus interfaces
repository. Optionally the interface
<filename>default.target</filename>.</para></listitem>
</varlistentry>
<varlistentry>
- <term><option>--running-as=</option></term>
+ <term><option>--system</option></term>
+ <term><option>--session</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
+ <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
+ (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>
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
+ 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>
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
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
+ to activate other services when file system
objects change or are modified. See
<citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
<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
+ <filename>default.target</filename> whose job 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
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
for details about these target units.</para>
- <para>Processes systemd spawns ared placed in
+ <para>Processes systemd spawns are placed in
individual Linux control groups named after the unit
which they belong to in the private systemd
hierarchy. (see <ulink
simply read as an alternative (though limited)
configuration file format. The SysV
<filename>/dev/initctl</filename> interface is
- provided, and comaptibility implementations of the
- various SysV client tools available. In addition to
- that various established Unix functionality such as
+ provided, and compatibility implementations of the
+ various SysV client tools are available. In addition to
+ that, various established Unix functionality such as
<filename>/etc/fstab</filename> or the
<filename>utmp</filename> database are
supported.</para>
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