<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
however some are created automatically from other configuration,
dynamically from system state or programmatically at runtime.
- Units may be "active" (meaning started, bound, plugged in, ...,
+ Units 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
+ 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
"failed" state is available as well, which is very similar to
<varlistentry>
<term><varname>systemd.confirm_spawn=</varname></term>
- <listitem><para>Takes a boolean argument. If
- <option>yes</option>, the system manager (PID 1) asks for
- confirmation when spawning processes. Defaults to
- <option>no</option>.</para></listitem>
+ <listitem><para>Takes a boolean argument or a path to the
+ virtual console where the confirmation messages should be
+ emitted. If <option>yes</option>, the system manager (PID 1)
+ asks for confirmation when spawning processes using
+ <option>/dev/console</option>. If a path or a console name
+ (such as <literal>ttyS0</literal>) is provided, the virtual
+ console pointed to by this path or described by the give name
+ will be used instead. Defaults to <option>no</option>.</para></listitem>
</varlistentry>
<varlistentry>