inspired by Microsoft Windows
<filename>.ini</filename> files.</para>
- <para>This man pages lists the common configuration
+ <para>This man page lists the common configuration
options of all the unit types. These options need to
- be configured in the [Unit] resp. [Install]
- section of the unit files.</para>
+ be configured in the [Unit] or [Install]
+ sections of the unit files.</para>
<para>In addition to the generic [Unit] and [Install]
sections described here, each unit should have a
<entry>User shell</entry>
<entry>This is the shell of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
</row>
+ <row>
+ <entry><literal>%m</literal></entry>
+ <entry>Machine ID</entry>
+ <entry>The machine ID of the running system, formatted as string. See <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+ </row>
+ <row>
+ <entry><literal>%b</literal></entry>
+ <entry>Boot ID</entry>
+ <entry>The boot ID of the running system, formatted as string. See <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.</entry>
+ </row>
+ <row>
+ <entry><literal>%H</literal></entry>
+ <entry>Host name</entry>
+ <entry>The host name of the running system.</entry>
+ </row>
</tbody>
</tgroup>
</table>
<literal>man:</literal>. For more
information about the syntax of these
URIs see
- <citerefentry><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
+ <citerefentry><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
+ URIs should be listed in order of
+ relevance, starting with the most
+ relevant. It is a good idea to first
+ reference documentation that explains
+ what the unit's purpose is, followed
+ by how it is configured, followed by
+ any other related
+ documentation.</para></listitem>
</varlistentry>
<varlistentry>
<listitem><para>Similar to
<varname>Requires=</varname>
- resp. <varname>RequiresOverridable=</varname>. However,
+ and <varname>RequiresOverridable=</varname>, respectively. However,
if a unit listed here is not started
already it will not be started and the
transaction fails
<varname>Before=</varname>. If two
units have no ordering dependencies
between them they are shut down
- resp. started up simultaneously, and
+ or started up simultaneously, and
no ordering takes
place. </para></listitem>
</varlistentry>
<listitem><para>Takes a boolean
argument. If <option>true</option>
this unit can only be activated
- (resp. deactivated) indirectly. In
+ or deactivated indirectly. In
this case explicit start-up
- (resp. termination) requested by the
+ or termination requested by the
user is denied, however if it is
- started (resp. stopped) as a
+ started or stopped as a
dependency of another unit, start-up
- (resp. termination) will succeed. This
+ or termination will succeed. This
is mostly a safety feature to ensure
that the user does not accidentally
activate units that are not intended
<listitem><para>Installs a symlink in
the <filename>.wants/</filename>
- resp. <filename>.requires/</filename>
- subdirectory for a unit. This has the
+ or <filename>.requires/</filename>
+ subdirectory for a unit, respectively. This has the
effect that when the listed unit name
is activated the unit listing it is
activated