Merge pull request #13131 from yuwata/pstore-follow-ups

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

diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml
index 651a73848ee983f74b65e8902ee27564ee07d42b..7112362ac5b1701dd2e719f859c8ceeb6d137346 100644 (file)
--- a/man/systemd-analyze.xml
+++ b/man/systemd-analyze.xml
@@ -83,6 +83,12 @@
       <arg choice="opt" rep="repeat">OPTIONS</arg>
       <arg choice="plain">unit-paths</arg>
     </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">condition</arg>
+      <arg choice="plain"><replaceable>CONDITION</replaceable>…</arg>
+    </cmdsynopsis>
     <cmdsynopsis>
       <command>systemd-analyze</command>
       <arg choice="opt" rep="repeat">OPTIONS</arg>
@@ -172,7 +178,13 @@ multi-user.target reached after 47.820s in userspace
       initialization of one service might be slow simply because it waits for the initialization of another
       service to complete.  Also note: <command>systemd-analyze blame</command> doesn't display results for
       services with <varname>Type=simple</varname>, because systemd considers such services to be started
-      immediately, hence no measurement of the initialization delays can be done.</para>
+      immediately, hence no measurement of the initialization delays can be done. Also note that this command
+      only shows the time units took for starting up, it does not show how long unit jobs spent in the
+      execution queue. In particular it shows the time units spent in <literal>activating</literal> state,
+      which is not defined for units such as device units that transition directly from
+      <literal>inactive</literal> to <literal>active</literal>. This command hence gives an impression of the
+      performance of program code, but cannot accurately reflect latency introduced by waiting for
+      hardware and similar events.</para>
 
       <example>
         <title><command>Show which units took the most time during boot</command></title>
@@ -196,7 +208,12 @@ multi-user.target reached after 47.820s in userspace
       <replaceable>UNIT</replaceable>s or for the default target otherwise). The time after the unit is
       active or started is printed after the "@" character. The time the unit takes to start is printed after
       the "+" character. Note that the output might be misleading as the initialization of services might
-      depend on socket activation and because of the parallel execution of units.</para>
+      depend on socket activation and because of the parallel execution of units. Also, similar to the
+      <command>blame</command> command, this only takes into account the time units spent in
+      <literal>activating</literal> state, and hence does not cover units that never went through an
+      <literal>activating</literal> state (such as device units that transition directly from
+      <literal>inactive</literal> to <literal>active</literal>). Moreover it does not show information on
+      jobs (and in particular not jobs that timed out).</para>
 
       <example>
         <title><command>systemd-analyze time</command></title>
@@ -348,6 +365,33 @@ $ eog targets.svg</programlisting>
       to retrieve the actual list that the manager uses, with any empty directories omitted.</para>
     </refsect2>
 
+    <refsect2>
+      <title><command>systemd-analyze condition <replaceable>CONDITION</replaceable>...</command></title>
+
+      <para>This command will evaluate <varname noindex='true'>Condition*=...</varname> and
+      <varname noindex='true'>Assert*=...</varname> assignments, and print their values, and
+      the resulting value of the combined condition set. See
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for a list of available conditions and asserts.</para>
+
+      <example>
+        <title>Evaluate conditions that check kernel versions</title>
+
+        <programlisting>$ systemd-analyze condition 'ConditionKernelVersion = ! &lt;4.0' \
+        'ConditionKernelVersion = &gt;=5.1' \
+        'ConditionACPower=|false' \
+        'ConditionArchitecture=|!arm' \
+        'AssertPathExists=/etc/os-release'
+test.service: AssertPathExists=/etc/os-release succeeded.
+Asserts succeeded.
+test.service: ConditionArchitecture=|!arm succeeded.
+test.service: ConditionACPower=|false failed.
+test.service: ConditionKernelVersion=&gt;=5.1 succeeded.
+test.service: ConditionKernelVersion=!&lt;4.0 succeeded.
+Conditions succeeded.</programlisting>
+      </example>
+    </refsect2>
+
     <refsect2>
       <title><command>systemd-analyze syscall-filter <optional><replaceable>SET</replaceable>...</optional></command></title>