mirror of
https://github.com/AuxXxilium/eudev.git
synced 2024-12-13 10:06:53 +07:00
man: extend man pages a little
This commit is contained in:
Lennart Poettering
parent
246756ca92
commit
b9975629f0
2
fixme
2
fixme
@ -49,8 +49,6 @@
|
||||
|
||||
* maintenance units müssen vergessen werden
|
||||
|
||||
* maintenance muss dokumentiert werden, ebenso OnStartup= und JobTimeoutSec=
|
||||
|
||||
* fingerprint.target, wireless.target, gps.target
|
||||
|
||||
* fix merging of device units
|
||||
|
||||
@ -398,6 +398,15 @@
|
||||
place. </para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>OnFailure=</varname></term>
|
||||
|
||||
<listitem><para>Lists one or more
|
||||
units that are activated when this
|
||||
unit fails (i.e. enters maintenance
|
||||
state).</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>RecursiveStop=</varname></term>
|
||||
|
||||
@ -495,6 +504,34 @@
|
||||
fails the unit will immediately fail
|
||||
too and the job is removed.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>JobTimeoutSec=</varname></term>
|
||||
|
||||
<listitem><para>When clients are
|
||||
waiting for a job of this unit to
|
||||
complete, time out after the specified
|
||||
time. If this time limit is reached
|
||||
the job will be cancelled, the unit
|
||||
however will not change state or even
|
||||
enter maintenance mode. This value
|
||||
defaults to 0 (job timeouts disabled),
|
||||
except for device units. NB: this
|
||||
timeout is independent from any
|
||||
unit-specific timeout (for example,
|
||||
the timeout set with
|
||||
<varname>Timeout=</varname> in service
|
||||
units) as the job timeout has no effect
|
||||
on the unit itself, only on the job
|
||||
that might be pending for it. Or in
|
||||
other words: unit-specific timeouts
|
||||
are useful to abort unit state
|
||||
changes, and revert them. The job
|
||||
timeout set with this option however
|
||||
is useful to abort only the job waiting
|
||||
for the unit state to change.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
<para>Unit file may include a [Install] section, which
|
||||
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user