]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
man: fix --ignore-inhibitors docs
authorLennart Poettering <lennart@poettering.net>
Tue, 17 Jul 2018 11:05:39 +0000 (13:05 +0200)
committerFilipe Brandenburger <filbranden@google.com>
Tue, 17 Jul 2018 16:49:04 +0000 (09:49 -0700)
Reported here:

https://lists.freedesktop.org/archives/systemd-devel/2018-June/040939.html

Also see:

https://lists.freedesktop.org/archives/systemd-devel/2018-July/041036.html

man/systemctl.xml

index a70bdb40d7f99ddd9a4b3c79640e0b48beb5e7de..d4a915e45655978d987fed28b55cb625b0e30ac9 100644 (file)
         <term><option>--ignore-inhibitors</option></term>
 
         <listitem>
-          <para>When system shutdown or a sleep state is requested,
-          ignore inhibitor locks. Applications can establish inhibitor
-          locks to avoid that certain important operations (such as CD
-          burning or suchlike) are interrupted by system shutdown or a
-          sleep state. Any user may take these locks and privileged
-          users may override these locks. If any locks are taken,
-          shutdown and sleep state requests will normally fail
-          (regardless of whether privileged or not) and a list of active locks
-          is printed. However, if <option>--ignore-inhibitors</option>
-          is specified, the locks are ignored and not printed, and the
-          operation attempted anyway, possibly requiring additional
-          privileges.</para>
+          <para>When system shutdown or a sleep state is requested, ignore inhibitor locks. Applications can establish
+          inhibitor locks to avoid that certain important operations (such as CD burning or suchlike) are interrupted
+          by system shutdown or a sleep state. Any user may take these locks and privileged users may override these
+          locks. If any locks are taken, shutdown and sleep state requests will normally fail (unless privileged) and a
+          list of active locks is printed. However, if <option>--ignore-inhibitors</option> is specified, the
+          established locks are ignored and not shown, and the operation attempted anyway, possibly requiring
+          additional privileges.</para>
         </listitem>
       </varlistentry>