<term><command>status</command> <optional><replaceable>PATTERN</replaceable>…|<replaceable>PID</replaceable>…]</optional></term>
<listitem>
- <para>Show terse runtime status information about one or
- more units, followed by most recent log data from the
- journal. If no units are specified, show system status. If
- combined with <option>--all</option>, also show the status of
- all units (subject to limitations specified with
- <option>-t</option>). If a PID is passed, show information
- about the unit the process belongs to.</para>
+ <para>Show runtime status information about the whole system or about one or more units followed
+ by most recent log data from the journal. If no positional arguments are specified, and no unit
+ filter is given with <option>--type=</option>, <option>--state=</option>, or
+ <option>--failed</option>, shows the status of the whole system. If combined with
+ <option>--all</option>, follows that with the status of all units. If positional arguments are
+ specified, each positional argument is treated as either a unit name to show, or a glob pattern
+ to show units whose names match that pattern, or a PID to show the unit containing that PID. When
+ <option>--type=</option>, <option>--state=</option>, or <option>--failed</option> are used, units
+ are additionally filtered by the TYPE and ACTIVE state.</para>
<para>This function is intended to generate human-readable
output. If you are looking for computer-parsable output,
Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output error (5)
</programlisting>
- <para>The dot ("●") uses color on supported terminals to summarize the unit state at a glance. Along with
- its color, its shape varies according to its state: <literal>inactive</literal> or
- <literal>maintenance</literal> is a white circle ("○"), <literal>active</literal> is a green dot ("●"),
- <literal>deactivating</literal> is a white dot, <literal>failed</literal> or <literal>error</literal> is
- a red cross ("×"), and <literal>reloading</literal> is a green clockwise circle arrow ("↻").
- </para>
-
- <para>The "Loaded:" line in the output will show <literal>loaded</literal> if the unit has been loaded into
- memory. Other possible values for "Loaded:" include: <literal>error</literal> if there was a problem
- loading it, <literal>not-found</literal> if no unit file was found for this unit,
- <literal>bad-setting</literal> if an essential unit file setting could not be parsed and
- <literal>masked</literal> if the unit file has been masked. Along with showing the path to the unit file,
- this line will also show the enablement state. Enabled commands start at boot. See the full table of
- possible enablement states — including the definition of <literal>masked</literal> — in the documentation
- for the <command>is-enabled</command> command.
+ <para>The dot ("●") uses color on supported terminals to summarize the unit state at a
+ glance. Along with its color, its shape varies according to its state:
+ <literal>inactive</literal> or <literal>maintenance</literal> is a white circle ("○"),
+ <literal>active</literal> is a green dot ("●"), <literal>deactivating</literal> is a white dot,
+ <literal>failed</literal> or <literal>error</literal> is a red cross ("×"), and
+ <literal>reloading</literal> is a green clockwise circle arrow ("↻").</para>
+
+ <para>The "Loaded:" line in the output will show <literal>loaded</literal> if the unit has been
+ loaded into memory. Other possible values for "Loaded:" include: <literal>error</literal> if
+ there was a problem loading it, <literal>not-found</literal> if no unit file was found for this
+ unit, <literal>bad-setting</literal> if an essential unit file setting could not be parsed and
+ <literal>masked</literal> if the unit file has been masked. Along with showing the path to the
+ unit file, this line will also show the enablement state. Enabled units are included in the
+ dependency network between units, and thus are started at boot or via some other form of
+ activation. See the full table of possible enablement states — including the definition of
+ <literal>masked</literal> — in the documentation for the <command>is-enabled</command> command.
</para>
<para>The "Active:" line shows active state. The value is usually <literal>active</literal> or
- <literal>inactive</literal>. Active could mean started, bound, plugged in, etc depending on the unit type.
- The unit could also be in process of changing states, reporting a state of <literal>activating</literal> or
- <literal>deactivating</literal>. A special <literal>failed</literal> state is entered when the service
- failed in some way, such as a crash, exiting with an error code or timing out. If the failed state is
- entered the cause will be logged for later reference.</para>
+ <literal>inactive</literal>. Active could mean started, bound, plugged in, etc depending on the
+ unit type. The unit could also be in process of changing states, reporting a state of
+ <literal>activating</literal> or <literal>deactivating</literal>. A special
+ <literal>failed</literal> state is entered when the service failed in some way, such as a crash,
+ exiting with an error code or timing out. If the failed state is entered the cause will be logged
+ for later reference.</para>
</example>
</listitem>
<term><option>--type=</option></term>
<listitem>
- <para>The argument should be a comma-separated list of unit
- types such as <option>service</option> and
- <option>socket</option>.
- </para>
+ <para>The argument is a comma-separated list of unit types such as <option>service</option> and
+ <option>socket</option>. When units are listed with <command>list-units</command>,
+ <command>show</command>, or <command>status</command>, only units of the specified types will be
+ shown. By default, units of all types are shown.</para>
- <para>If one of the arguments is a unit type, when listing
- units, limit display to certain unit types. Otherwise, units
- of all types will be shown.</para>
-
- <para>As a special case, if one of the arguments is
- <option>help</option>, a list of allowed values will be
- printed and the program will exit.</para>
+ <para>As a special case, if one of the arguments is <option>help</option>, a list of allowed values
+ will be printed and the program will exit.</para>
</listitem>
</varlistentry>
<term><option>--state=</option></term>
<listitem>
- <para>The argument should be a comma-separated list of unit
- LOAD, SUB, or ACTIVE states. When listing units, show only
- those in the specified states. Use <option>--state=failed</option>
- to show only failed units.</para>
-
- <para>As a special case, if one of the arguments is
- <option>help</option>, a list of allowed values will be
- printed and the program will exit.</para>
+ <para>The argument is a comma-separated list of unit LOAD, SUB, or ACTIVE states. When listing
+ units with <command>list-units</command>, <command>show</command>, or <command>status</command>,
+ show only those in the specified states. Use <option>--state=failed</option> or
+ <option>--failed</option> to show only failed units.</para>
+
+ <para>As a special case, if one of the arguments is <option>help</option>, a list of allowed values
+ will be printed and the program will exit.</para>
</listitem>
</varlistentry>
<term><option>--check-inhibitors=</option></term>
<listitem>
- <para>When system shutdown or sleep state is request, this option controls how to deal with
- inhibitor locks. It takes one of <literal>auto</literal>, <literal>yes</literal> or
+ <para>When system shutdown or sleep state is requested, this option controls checking of inhibitor
+ locks. It takes one of <literal>auto</literal>, <literal>yes</literal> or
<literal>no</literal>. Defaults to <literal>auto</literal>, which will behave like
- <literal>yes</literal> for interactive invocations (i.e. from a TTY) and <literal>no</literal>
- for non-interactive invocations.
- <literal>yes</literal> will let the request respect inhibitor locks.
- <literal>no</literal> will let the request ignore inhibitor locks.
- </para>
- <para>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 <literal>no</literal> is specified or <literal>auto</literal> is specified on a
- non-interactive requests, the established locks are ignored and not shown, and the operation
- attempted anyway, possibly requiring additional privileges.
- May be overridden by <option>--force</option>.</para>
+ <literal>yes</literal> for interactive invocations (i.e. from a TTY) and <literal>no</literal> for
+ non-interactive invocations. <literal>yes</literal> lets the request respect inhibitor locks.
+ <literal>no</literal> lets the request ignore inhibitor locks.</para>
+
+ <para>Applications can establish inhibitor locks to prevent certain important operations (such as
+ CD burning) from being interrupted by system shutdown or sleep. 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). However, if <literal>no</literal> is specified or
+ <literal>auto</literal> is specified on a non-interactive requests, the operation will be
+ attempted. If locks are present, the operation may require additional privileges.</para>
+
+ <para>Option <option>--force</option> provides another way to override inhibitors.</para>
</listitem>
</varlistentry>
projects / thirdparty / systemd.git / blobdiff