<varname>Wanted=</varname> see below. The preferred
way to create symlinks in the
<filename>.wants/</filename> directory of a service is
- with the
- <citerefentry><refentrytitle>systemd-install</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ with the <command>enable</command> command of the
+ <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
tool which reads information from the [Install]
section of unit files. (See below.)</para>
respectively. The prefix name here refers to the
string before the @, i.e. "getty" in the example
above, where "tty3" is the instance name.</para>
+
+ <para>The unit file format is covered by the
+ <ulink
+ url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
+ Stability Promise</ulink>.</para>
</refsect1>
<refsect1>
independent of and orthogonal to the
<varname>After=</varname> and
<varname>Before=</varname> ordering
- dependencies.</para></listitem>
+ dependencies.</para>
+
+ <para>If a unit A that conflicts with
+ a unit B is scheduled to be started at
+ the same time as B, the transaction
+ will either fail (in case both are
+ required part of the transaction) or
+ be modified to be fixed (in case one
+ or both jobs are not a required part
+ of the transaction). In the latter
+ case the job that is not the required
+ will be removed, or in case both are
+ not required the unit that conflicts
+ will be started and the unit that is
+ conflicted is
+ stopped.</para></listitem>
</varlistentry>
<varlistentry>
<listitem><para>Lists one or more
units that are activated when this
- unit fails (i.e. enters maintenance
- state).</para></listitem>
+ unit enters the
+ '<literal>failed</literal>'
+ state.</para></listitem>
</varlistentry>
<varlistentry>
</varlistentry>
<varlistentry>
- <term><varname>OnlyByDependency=</varname></term>
+ <term><varname>RefuseManualStart=</varname></term>
+ <term><varname>RefuseManualStop=</varname></term>
<listitem><para>Takes a boolean
argument. If <option>true</option>
this unit can only be activated
- indirectly. In this case explicit
- start-up requested by the user is
- denied, however if it is started as a
+ (resp. deactivated) indirectly. In
+ this case explicit start-up
+ (resp. termination) requested by the
+ user is denied, however if it is
+ started (resp. stopped) as a
dependency of another unit, start-up
- will succeed. This is mostly a safety
- feature to ensure that the user does
- not accidentally activate units that are
- not intended to be activated
- explicitly. This option defaults to
+ (resp. termination) will succeed. This
+ is mostly a safety feature to ensure
+ that the user does not accidentally
+ activate units that are not intended
+ to be activated explicitly, and not
+ accidentally deactivate units that are
+ not intended to be deactivated.
+ These options default to
+ <option>false</option>.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>AllowIsolate=</varname></term>
+
+ <listitem><para>Takes a boolean
+ argument. If <option>true</option>
+ this unit may be used with the
+ <command>systemctl isolate</command>
+ command. Otherwise this will be
+ refused. It probably is a good idea to
+ leave this disabled except for target
+ units that shall be used similar to
+ runlevels in SysV init systems, just
+ as a precaution to avoid unusable
+ system states. This option defaults to
<option>false</option>.</para></listitem>
</varlistentry>
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
+ enter the '<literal>failed</literal>'
+ 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
+ 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>
+ is useful to abort only the job
+ waiting for the unit state to
+ change.</para></listitem>
</varlistentry>
</variablelist>
section is not interpreted by
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
during runtime. It is used exclusively by the
- <citerefentry><refentrytitle>systemd-install</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ <command>enable</command> and
+ <command>disable</command> commands of the
+ <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
tool during installation of a unit:</para>
<variablelist>
more than once, in which case all
listed names are used. At installation
time,
- <command>systemd-install</command>
+ <command>systemctl enable</command>
will create symlinks from these names
to the unit file name. Note that this
is different from the
<varname>Alias=</varname> apply only
if the unit has actually been
installed with the
- <command>systemd-install</command>
- tool. Also, if systemd searches for a
+ <command>systemctl enable</command>
+ command. Also, if systemd searches for a
unit, it will discover symlinked alias
names as configured with
<varname>Alias=</varname>, but not
installed. If the user requests
installation of a unit with this
option configured,
- <command>systemd-install</command>
+ <command>systemctl enable</command>
will automatically install units
listed in this option as
well.</para></listitem>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd-install</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
~ianmdlvl / elogind.git / blobdiff