SymbX/systemd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #6202 from poettering/condition-first-boot-doc

Browse Source 
some documentation updates
This commit is contained in:
Zbigniew Jędrzejewski-Szmek
2017-06-27 18:34:18 -04:00
committed by GitHub
parent eca2995c51 2eb6ff5e71
commit f9ce1a4a41
2 changed files with 35 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
man/systemd.service.xml
+7 -8
View File
@@ -328,14 +328,13 @@
all <varname>ExecStartPre=</varname> commands that were not prefixed
with a <literal>-</literal> exit successfully.</para>
<para><varname>ExecStartPost=</varname> commands are only run after
the service has started successfully, as determined by <varname>Type=</varname>
(i.e. the process has been started for <varname>Type=simple</varname>
or <varname>Type=idle</varname>, the process exits successfully for
<varname>Type=oneshot</varname>, the initial process exits successfully
for <varname>Type=forking</varname>, <literal>READY=1</literal> is sent
for <varname>Type=notify</varname>, or the <varname>BusName=</varname>
has been taken for <varname>Type=dbus</varname>).</para>
<para><varname>ExecStartPost=</varname> commands are only run after the commands specified in
<varname>ExecStart=</varname> have been invoked successfully, as determined by <varname>Type=</varname>
(i.e. the process has been started for <varname>Type=simple</varname> or <varname>Type=idle</varname>, the last
<varname>ExecStart=</varname> process exited successfully for <varname>Type=oneshot</varname>, the initial
process exited successfully for <varname>Type=forking</varname>, <literal>READY=1</literal> is sent for
<varname>Type=notify</varname>, or the <varname>BusName=</varname> has been taken for
<varname>Type=dbus</varname>).</para>
<para>Note that <varname>ExecStartPre=</varname> may not be
used to start long-running processes. All processes forked
man/systemd.unit.xml
+28 -27
View File
@@ -546,26 +546,29 @@
<term><varname>Before=</varname></term>
<term><varname>After=</varname></term>
<listitem><para>A space-separated list of unit names. Configures ordering dependencies between units. If a
unit <filename>foo.service</filename> contains a setting <option>Before=bar.service</option> and both units are
being started, <filename>bar.service</filename>'s start-up is delayed until <filename>foo.service</filename> is
started up. Note that this setting is independent of and orthogonal to the requirement dependencies as
configured by <varname>Requires=</varname>, <varname>Wants=</varname> or <varname>BindsTo=</varname>. It is a
common pattern to include a unit name in both the <varname>After=</varname> and <varname>Requires=</varname>
option, in which case the unit listed will be started before the unit that is configured with these
options. This option may be specified more than once, in which case ordering dependencies for all listed names
are created. <varname>After=</varname> is the inverse of <varname>Before=</varname>, i.e. while
<varname>After=</varname> ensures that the configured unit is started after the listed unit finished starting
up, <varname>Before=</varname> ensures the opposite, i.e. that the configured unit is fully started up before
the listed unit is started. Note that when two units with an ordering dependency between them are shut down,
the inverse of the start-up order is applied. i.e. if a unit is configured with <varname>After=</varname> on
another unit, the former is stopped before the latter if both are shut down. Given two units with any ordering
dependency between them, if one unit is shut down and the other is started up, the shutdown is ordered before
the start-up. It doesn't matter if the ordering dependency is <varname>After=</varname> or
<varname>Before=</varname>, in this case. It also doesn't matter which of the two is shut down, as long as one
is shut down and the other is started up. The shutdown is ordered before the start-up in all cases. If two
units have no ordering dependencies between them, they are shut down or started up simultaneously, and no
ordering takes place. </para></listitem>
<listitem><para>These two settings expect a space-separated list of unit names. They configure ordering
dependencies between units. If a unit <filename>foo.service</filename> contains a setting
<option>Before=bar.service</option> and both units are being started, <filename>bar.service</filename>'s
start-up is delayed until <filename>foo.service</filename> has finished starting up. Note that this setting is
independent of and orthogonal to the requirement dependencies as configured by <varname>Requires=</varname>,
<varname>Wants=</varname> or <varname>BindsTo=</varname>. It is a common pattern to include a unit name in both
the <varname>After=</varname> and <varname>Requires=</varname> options, in which case the unit listed will be
started before the unit that is configured with these options. This option may be specified more than once, in
which case ordering dependencies for all listed names are created. <varname>After=</varname> is the inverse of
<varname>Before=</varname>, i.e. while <varname>After=</varname> ensures that the configured unit is started
after the listed unit finished starting up, <varname>Before=</varname> ensures the opposite, that the
configured unit is fully started up before the listed unit is started. Note that when two units with an
ordering dependency between them are shut down, the inverse of the start-up order is applied. i.e. if a unit is
configured with <varname>After=</varname> on another unit, the former is stopped before the latter if both are
shut down. Given two units with any ordering dependency between them, if one unit is shut down and the other is
started up, the shutdown is ordered before the start-up. It doesn't matter if the ordering dependency is
<varname>After=</varname> or <varname>Before=</varname>, in this case. It also doesn't matter which of the two
is shut down, as long as one is shut down and the other is started up. The shutdown is ordered before the
start-up in all cases. If two units have no ordering dependencies between them, they are shut down or started
up simultaneously, and no ordering takes place. It depends on the unit type when precisely a unit has finished
starting up. Most importantly, for service units start-up is considered completed for the purpose of
<varname>Before=</varname>/<varname>After=</varname> when all its configured start-up commands have been
invoked and they either failed or reported start-up success.</para></listitem>
</varlistentry>
<varlistentry>
@@ -980,13 +983,11 @@
to make sure they run before the stamp file's modification
time gets reset indicating a completed update.</para>
<para><varname>ConditionFirstBoot=</varname> takes a boolean
argument. This condition may be used to conditionalize units
on whether the system is booting up with an unpopulated
<filename>/etc</filename> directory. This may be used to
populate <filename>/etc</filename> on the first boot after
factory reset, or when a new system instances boots up for the
first time.</para>
<para><varname>ConditionFirstBoot=</varname> takes a boolean argument. This condition may be used to
conditionalize units on whether the system is booting up with an unpopulated <filename>/etc</filename>
directory (specifically: an <filename>/etc</filename> with no <filename>/etc/machine-id</filename>). This may
be used to populate <filename>/etc</filename> on the first boot after factory reset, or when a new system
instance boots up for the first time.</para>
<para>With <varname>ConditionPathExists=</varname> a file
existence condition is checked before a unit is started. If