summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMark Stosberg <mark@rideamigos.com>2016-12-21 14:55:04 -0500
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2017-01-14 17:43:32 -0500
commitab8864ebc3ac01288729b44f0d5f18fff37defb5 (patch)
treeaaa445ebfeadeeefc9a3eaecded89deafc7375f0
parente843b04ee95815e862d9d4399ca99680b2b6f6ea (diff)
man: provide a basic guide to the `systemctl status` output (#4950)
- Show example of all `systemctl status` output and documents what possible "Loaded:", "Active" and "Enabled" values mean. - Documents what different colors of the dot mean. - Documents "gotcha" with load-on-demand behavior which will report units as "loaded" even if they are only loaded to show their status. (From @poettering: https://github.com/systemd/systemd/issues/5063#issuecomment-272115024 )
-rw-r--r--man/systemctl.xml50
1 files changed, 50 insertions, 0 deletions
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 1440d71925..391e5dfe9c 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -876,6 +876,56 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
a similar filter for messages and might be more
convenient.
</para>
+
+ <para>Systemd implicitly loads units as necessary, so just running the <command>status</command> will
+ attempt to load a file. The command is thus not useful for determining if something was already loaded or
+ not. The units may possibly also be quickly unloaded after the operation is completed if there's no reason
+ to keep it in memory thereafter.
+ </para>
+
+ <example>
+ <title>Example output from systemctl status </title>
+
+ <programlisting>$ systemctl status bluetooth
+● bluetooth.service - Bluetooth service
+ Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
+ Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago
+ Docs: man:bluetoothd(8)
+ Main PID: 930 (bluetoothd)
+ Status: "Running"
+ Tasks: 1
+ Memory: 648.0K
+ CPU: 435ms
+ CGroup: /system.slice/bluetooth.service
+ └─930 /usr/lib/bluetooth/bluetoothd
+
+Jan 12 10:46:45 example.com bluetoothd[8900]: Not enough free handles to register service
+Jan 12 10:46:45 example.com.com bluetoothd[8900]: Current Time Service could not be registered
+Jan 12 10:46:45 example.com.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. White
+ indicates an <literal>inactive</literal> or <literal>deactivating</literal> state. Red indicates a
+ <literal>failed</literal> or <literal>error</literal> state and green indicates an
+ <literal>active</literal>, <literal>reloading</literal> or <literal>activating</literal> state.
+ </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>, and <literal>masked</literal>. 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>
+
+ <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>
+ </example>
+
</listitem>
</varlistentry>
<varlistentry>