Merge pull request #11580 from yuwata/fix-11579

[thirdparty/systemd.git] / man / systemd.xml

diff --git a/man/systemd.xml b/man/systemd.xml
index b166e534a5af0e6a05b71eb48dc38a5e91aa774f..5287bdaba89a47a4c1af0f5f88b80cace01d52b3 100644 (file)
--- a/man/systemd.xml
+++ b/man/systemd.xml
@@ -396,7 +396,7 @@
     loaded into memory are those for which at least one of the following conditions is true:</para>
 
     <orderedlist>
-      <listitem><para>It is in an active, activating, deactivating or failed state (i.e. in any unit state except for <literal>dead</literal>)</para></listitem>
+      <listitem><para>It is in an active, activating, deactivating or failed state (i.e. in any unit state except for <literal>inactive</literal>)</para></listitem>
       <listitem><para>It has a job queued for it</para></listitem>
       <listitem><para>It is a dependency of some sort of at least one other unit that is loaded into memory</para></listitem>
       <listitem><para>It has some form of resource still allocated (e.g. a service unit that is inactive but for which
@@ -453,6 +453,17 @@
     verify that it makes sense, fixing it if possible, and only
     failing if it really cannot work.</para>
 
+    <para>Note that transactions are generated independently of a unit's
+    state at runtime, hence, for example, if a start job is requested on an
+    already started unit, it will still generate a transaction and wake up any
+    inactive dependencies (and cause propagation of other jobs as per the
+    defined relationships). This is because the enqueued job is at the time of
+    execution compared to the target unit's state and is marked successful and
+    complete when both satisfy. However, this job also pulls in other
+    dependencies due to the defined relationships and thus leads to, in our
+    our example, start jobs for any of those inactive units getting queued as
+    well.</para>
+
     <para>systemd contains native implementations of various tasks
     that need to be executed as part of the boot process. For example,
     it sets the hostname or configures the loopback network device. It
@@ -580,16 +591,15 @@
       <varlistentry>
         <term><constant>SIGINT</constant></term>
 
-        <listitem><para>Upon receiving this signal the systemd system
-        manager will start the
-        <filename>ctrl-alt-del.target</filename> unit. This is mostly
-        equivalent to <command>systemctl start ctrl-alt-del.target
-        --job-mode=replace-irreversible</command>. If this signal is
-        received more than 7 times per 2s, an immediate reboot is
-        triggered.  Note that pressing Ctrl-Alt-Del on the console
-        will trigger this signal. Hence, if a reboot is hanging,
-        pressing Ctrl-Alt-Del more than 7 times in 2s is a relatively
-        safe way to trigger an immediate reboot.</para>
+        <listitem><para>Upon receiving this signal the systemd system manager will start the
+        <filename>ctrl-alt-del.target</filename> unit. This is mostly equivalent to
+        <command>systemctl start ctrl-alt-del.target --job-mode=replace-irreversible</command>. If
+        this signal is received more than 7 times per 2s, an immediate reboot is triggered. Note
+        that pressing
+        <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> on the
+        console will trigger this signal. Hence, if a reboot is hanging, pressing
+        <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> more than
+        7 times in 2 seconds is a relatively safe way to trigger an immediate reboot.</para>
 
         <para>systemd user managers treat this signal the same way as
         <constant>SIGTERM</constant>.</para></listitem>