]> git.ipfire.org Git - thirdparty/systemd.git/blobdiff - man/systemd.xml
man: use unicode ellipsis in more places
[thirdparty/systemd.git] / man / systemd.xml
index 367972099b687b6fd1e46c12845bf0e63ddd0da9..50398e6259e721f87c974ea70045f2522135a581 100644 (file)
         <term><option>--machine-id=</option></term>
 
         <listitem><para>Override the machine-id set on the hard drive,
-        userful for network booting or for containers. May not be set
+        useful for network booting or for containers. May not be set
         to all zeros.</para></listitem>
       </varlistentry>
 
     <title>Concepts</title>
 
     <para>systemd provides a dependency system between various
-    entities called "units" of 12 different types. Units encapsulate
+    entities called "units" of 11 different types. Units encapsulate
     various objects that are relevant for system boot-up and
     maintenance. The majority of units are configured in unit
     configuration files, whose syntax and basic set of options is
     <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
         script runlevel link farms.</para></listitem>
       </varlistentry>
 
+      <varlistentry>
+        <term><varname>$SYSTEMD_COLORS</varname></term>
+
+        <listitem><para>The value must be a boolean. Controls whether colorized output should be
+        generated. This can be specified to override the decision that <command>systemd</command>
+        makes based on <varname>$TERM</varname> and what the console is connected to.</para>
+        </listitem>
+      </varlistentry>
+
       <varlistentry>
         <term><varname>$LISTEN_PID</varname></term>
         <term><varname>$LISTEN_FDS</varname></term>
         <listitem><para>Set by systemd for supervised processes during
         socket-based activation. See
         <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
-        for more information. </para></listitem>
+        for more information.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         <listitem><para>Set by systemd for supervised processes for
         status and start-up completion notification. See
         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
-        for more information. </para></listitem>
+        for more information.</para></listitem>
       </varlistentry>
     </variablelist>
   </refsect1>
       <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>
 
       <varlistentry>
         <term><varname>emergency</varname></term>
+        <term><varname>rd.emergency</varname></term>
         <term><varname>-b</varname></term>
 
         <listitem><para>Boot into emergency mode. This is equivalent
-        to <varname>systemd.unit=emergency.target</varname> and
-        provided for compatibility reasons and to be easier to
-        type.</para></listitem>
+        to <varname>systemd.unit=emergency.target</varname> or
+        <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
+        provided for compatibility reasons and to be easier to type.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         <term><varname>rescue</varname></term>
+        <term><varname>rd.rescue</varname></term>
         <term><varname>single</varname></term>
         <term><varname>s</varname></term>
         <term><varname>S</varname></term>
         <term><varname>1</varname></term>
 
         <listitem><para>Boot into rescue mode. This is equivalent to
-        <varname>systemd.unit=rescue.target</varname> and provided for
-        compatibility reasons and to be easier to
-        type.</para></listitem>
+        <varname>systemd.unit=rescue.target</varname> or
+        <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
+        provided for compatibility reasons and to be easier to type.</para></listitem>
       </varlistentry>
 
       <varlistentry>